Welcome to ITBlogs Sign in | Join | Help

Методологии III. Работа над ошибками

Меня справедливо упрекнули в том, что вместо того, чтобы перечислить Agile-принципы я указал признаки гибкой технологии. Итак, исправляю эту ошибку. Формально говоря, методология, называющая себя «гибкой» должна следовать следующему манифесту, в котором перечислены основные ценности Agile http://agilemanifesto.org/:
  • Люди и их взаимодействие, чем процессы и средства

  • Работающее ПО, чем исчерпывающая документация

  • Сотрудничество с заказчиком, чем обсуждение условий контракта

  • Реагирование на изменения, чем следование плану

Принципы, лежащие в основе манифеста Agile

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

  • Приветствуйте изменения требований даже на поздних этапах разработки. Agile-процессы готовы к таким изменениям ради достижения заказчиком конкурентного преимущества.

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

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

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

  • Самый действенный и эффективный способ обмена информацией как внутри команды разработчиков, так и разработчиков с внешним миром - непосредственное общение.

  • Работающее ПО - главный индикатор продвижения проекта.

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

  • Постоянное стремление к техническому совершенству и хороший дизайн системы повышают agility.

  • Важна простота - искусство увеличения  объема работ, которых удалось избежать.

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

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

Февраль 2001 года

Нетрудно видеть, что http://agilemanifesto.org/authors.html авторы, создавшие его — люди уже использующие существовавшие на то время Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming и т.д. Таким образом, Agile обобщает накопленный опыт. Говоря формально, на мой взгляд, адаптивный подход определяет общую модель Agile, как я это попытался показать в одной из предыдущих статей. Возможно, я не прав.


Crystal

В комментариях прозвучал вопрос, «а что делать когда есть жесткие рамки требований и жесткий бюджет? Если там место Agile?»

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

  • чем больше команда, тем "тяжелее" должна быть используемая методология;

  • чем критичнее проект, тем выше должна быть "плотность" методологии;

  • чем "тяжелее" методология, тем выше стоимость проекта;

  • самая эффективная форма коммуникации - непосредственное общение.

К примеру, методология XP по этой классификации относится к прозрачной D6 (6 человек), но при желании может быть расширена для проекта D14. D — в данном случае показатель критичности проекта: системы, сбой которой может привести к потере несущественной суммы (C — Comfort, D — Discretionary money, E — Essential money, L — Life).

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

Published 18 апреля 2008 г. 14:15 by DenisM
Filed under:

Comments

No Comments
Anonymous comments are disabled