Опубликован: 17.06.2015 | Уровень: для всех | Доступ: платный
Лекция 4:

Принципы agile

< Лекция 3 || Лекция 4: 123 || Лекция 5 >
Аннотация: Изучая специфические практики и артефакты agile разработки, можно найти несколько общих принципов – методологических правил, выражающих общий взгляд на то, как должно разрабатываться ПО. Начнем рассмотрение этих принципов – основы agile подхода.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Agile принципы

Организационные

  1. Поставить клиента в центр.
  2. Разрешать самоорганизацию команды.
  3. Сохранять устойчивый темп разработки.
  4. Разрабатывать минимально необходимое ПО:
    1. Создавать минимальную функциональность.
    2. Создавать только запрашиваемый продукт.
    3. Разрабатывать только код и тесты.
  5. Допускать изменения.
Технические
  1. Вести разработку итеративно:
    1. Выполнять частые рабочие итерации.
    2. Замораживать требования на время итерации.
  2. Рассматривать тесты как ключевой ресурс: .
    1. Никакую новую разработку не начинать, пока не пройдут все тесты.
    2. Вначале тесты.
  3. Выражать требования через сценарии.

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

< Лекция 3 || Лекция 4: 123 || Лекция 5 >
Алексей Задойный
Алексей Задойный

В главе "5: Роли agile" http://www.intuit.ru/studies/courses/3505/747/lecture/26297?page=2 есть упоминание:

Скримшир [Scrimshire сайт]

но нет адреса сайта. Укажите пожалуйста адрес в тексте лекции.

Или речь о человеке James Scrimshire?

Павел Плахотник
Павел Плахотник

http://www.intuit.ru/studies/courses/3505/747/lecture/26293

Сделайте пожалуйста вопросы более корректными. Это сложно конечно. Но надо четко понимать что именно имеется в виду.

По предварительному анализу, водопаду, документам требований вообще не понятно что имеется в виду. Возможно надо будет изменить авторский текст, но всё же ясность и конкретность важна. А её нет.