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

15 июня 2017, 13:08
0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Только для читателей Cossa — скидка 50% на электронную книгу «Постигая Agile». Промокод: 1506mif. Действует до завтра, 16 июня, 23:59 (мск).

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

Ответить?
Введите капчу

✉️✨
Письма Коссы — лаконичная рассылка для тех, кто ценит своё время: cossa.pulse.is