в вишлисте
Личная скидка {{ profile.personalDiscount.discount }}%
в корзине
на сумму
До бесплатной доставки
осталось
{{ cartCount + cartEbookCount }}
Корзина
Доставка в город {{ headerCity.name }}
сегодня от  бесплатно от {{ headerCity.estimatesMin }} до {{ headerCity.estimatesMax }}  бесплатно
В город {{ headerCity.name }}
пока не доставляем
Посмотрите
другие города
Город, населенный пункт
{{ city.region }}
Сюда пока не доставляем книги
Постигая Agile
12 принципов гибкой разработки программного обеспечения
31 мая 2017 4 883 просмотра
Постигая Agile
12 принципов гибкой разработки программного обеспечения
31 мая 2017 4 883 просмотра

Сергей Капличный
Сергей Капличный

Опытные Agile-коучи Эндрю Стеллман и Дженнифер Грин подготовили книгу «Постигая Agile», в которой рассказывают о том, как команды используют гибкие методологии для создания программ, как с помощью Agile добиться впечатляющих результатов и каких принципов должны придерживаться Agile-команды. Именно о принципах гибкой разработки мы сегодня и поговорим.

Итак, перед вами 12 принципов гибкой разработки программного обеспечения.

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

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

Изменения в требованиях приветствуются даже на поздних этапах реализации проекта.

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

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

Чем чаще, тем лучше. Это позволит планировать и внедрять любые изменения.

Наиболее эффективный и действенный способ передачи информации — это встреча членов команды разработки ПО.

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

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

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

Проекты строятся вокруг мотивированных людей.

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

Рабочее программное обеспечение — это главная мера прогресса проекта.

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

Гибкие процессы способствуют непрерывному развитию.

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

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

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

Простота — это искусство не делать лишней работы.

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

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

В agile-команде каждый несет свою долю ответственности за архитектуру. Старший архитектор программного обеспечения или дизайнер, как и прежде, играет важную роль, но при этом не может работать в изоляции. В самом деле, когда команда создает программное обеспечение по частям, начиная с наиболее ценных частей, работа архитектора становится сложнее (но часто и интереснее). Вместо формирования в начале проекта одной большой конструкции, охватывающей все требования, agile-архитекторы используют инкрементальный дизайн, включающий в себя методы разработки, позволяющие не только создавать полную систему, но и легко вносить в нее изменения.

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

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

По материалам книги «Постигая Agile».

Похожие статьи