Опытные Agile-коучи Эндрю Стеллман и Дженнифер Грин подготовили книгу «Постигая Agile», в которой рассказывают о том, как команды используют гибкие методологии для создания программ, как с помощью Agile добиться впечатляющих результатов и каких принципов должны придерживаться Agile-команды. Именно о принципах гибкой разработки мы сегодня и поговорим.
Итак, перед вами 12 принципов гибкой разработки программного обеспечения.
Наивысший приоритет — это удовлетворение заказчика при помощи частых и непрерывных поставок ценного для него программного обеспечения.
Чтобы соответсвовать этому принципу гибкие методологии, как правило, являются итеративными. Agile-команды планируют итерации проекта путем выбора показателей и требований, которые обеспечивают максимальную отдачу. Единственный способ, при помощи которого команда может выяснить, какие показатели реализуют эту ценность, — сотрудничество с клиентом и встраивание обратной связи от предыдущей итерации.
Изменения в требованиях приветствуются даже на поздних этапах реализации проекта.
Мы учимся на изменениях. Это наиболее эффективный способ командного роста и строительства лучшего ПО.
Работающий продукт следует выпускать каждые несколько недель, в крайнем случае — каждые несколько месяцев.
Чем чаще, тем лучше. Это позволит планировать и внедрять любые изменения.
Наиболее эффективный и действенный способ передачи информации — это встреча членов команды разработки ПО.
Без чувства общности люди, исполняющие разные роли, будут вынуждены работать гораздо больше, чтобы их видение совпадало. Чем выше в команде чувство общности, чем ближе по взглядам ее члены, тем чаще каждый будет самостоятельно приходить к аналогичному ответу, когда начнет сталкиваться с возникавшим ранее вопросом. Это дает стабильную почву для управления изменениями, потому что конфликты остаются в прошлом и можно с уверенностью начать работу над кодом, причем не придется отвлекаться на управление документацией.
Представители бизнеса и команда разработки должны работать над проектом вместе.
Для создания хорошего программного продукта команда должна часто встречаться с предпринимателями, потому что ей необходимо получить доступ к знаниям, нужным для решения проблем при помощи ПО.
Проекты строятся вокруг мотивированных людей.
Создайте для cсотрудников подходящую окружающую среду, снабдите всем необходимым и доверьте сделать свою работу.
Рабочее программное обеспечение — это главная мера прогресса проекта.
Предоставляя работающие программные продукты по окончании каждой итерации и демонстрируя, что именно сделала команда, они держат всех в курсе того, на каком этапе находится проект. Поэтому практически невозможно неправильно истолковать ситуацию.
Гибкие процессы способствуют непрерывному развитию.
Agile-команды стремятся к сохранению устойчивого темпа. Они планируют выполнение задания, которое действительно можно сделать за выделенное для него время. Итеративная разработка позволяет добиваться этого. Намного проще оценить, сколько программных продуктов можно разработать в течение двух, четырех или шести недель, чем за год-полтора. Давая реальные обещания, команда создает среду, в которой работа по ночам — это исключение из правил.
Постоянное внимание к техническому совершенству и качественной архитектуре способствует гибкости.
Agile-разработчики приобретают большое количество навыков, помогающих им создавать хорошо спроектированный код. Они находятся в постоянном поиске дизайна и ошибок в коде и немедленно их исправляют. Если во время работы над проектом уделять немного больше внимания написанию надежного кода и исправлению ошибок, то можно создать надежную основу кода, которую можно легко поддерживать в будущем.
Простота — это искусство не делать лишней работы.
Наиболее эффективный способ создания максимально полезного и ценного программного обеспечения — это работа с клиентами и заинтересованными сторонами. Если функция не является ценной, то в долгосрочной перспективе для компании дешевле не создавать ее вовсе.
Лучшая архитектура, требования и дизайн создаются в самоорганизующихся командах.
В agile-команде каждый несет свою долю ответственности за архитектуру. Старший архитектор программного обеспечения или дизайнер, как и прежде, играет важную роль, но при этом не может работать в изоляции. В самом деле, когда команда создает программное обеспечение по частям, начиная с наиболее ценных частей, работа архитектора становится сложнее (но часто и интереснее). Вместо формирования в начале проекта одной большой конструкции, охватывающей все требования, agile-архитекторы используют инкрементальный дизайн, включающий в себя методы разработки, позволяющие не только создавать полную систему, но и легко вносить в нее изменения.
Команда постоянно ищет способы стать более эффективной путем настройки и коррекции своих действий.
Команда не может быть гибкой, если не совершенствует способы создания программного обеспечения. Agile-команды постоянно занимаются контролем и адаптацией — они следят за тем, как работают их проекты, и используют эти знания для улучшений в будущем. И делают это не только в конце проекта — на ежедневных встречах члены команды ищут пути изменения и меняют текущую работу, если в этом есть необходимость.
По материалам книги «Постигая Agile».
