Agile-менеджмент. Лидерство и управление командами - стр. 31
Прежде всего Agile-методологии признают за людьми их уникальность и не относятся к ним как к взаимозаменяемым ресурсам. Также признается, что основную ценность представляют взаимодействия и сотрудничество между людьми, а не их индивидуальные компетенции. Данный подход также предполагает работу в небольших кросс-функциональных командах, объединяющих людей, выполняющих разные роли (разработчиков, дизайнеров, тестировщиков и так далее). Предпочтительным вариантом будет размещение команды в одном помещении. От команды требуется самоорганизоваться, что означает отсутствие навязываемых извне методов или рабочих процессов. Команде доверяется выполнение определенной работы, исходя из представления, что ее члены знают, как эту работу выполнить, и осознают свою ответственность за результат.
В рамках Agile-методологий признается, что лучшие программные продукты создаются в условиях, когда заказчик максимально вовлечен в процесс разработки. Команда сотрудничает с заказчиком (или его представителем), поддерживая в актуальном состоянии backlog проекта и постоянно обновляя совместные приоритеты. Описание желаемой функциональности осуществляется в предельно кратком виде и детализируется только непосредственно перед началом работы над ней. Простота будет ключом к хорошему дизайну каждой из функциональных возможностей. Полезность данной функциональности оценивается и подтверждается клиентом сразу же после ее создания.
Качество играет определяющую роль в успехе продукта, поэтому в центре внимания Agile-методологий находится техническое совершенство. Высокий технический уровень обеспечивается посредством разработки через тестирование (написание протокола тестирования готового продукта предшествует созданию собственно программного кода), ревью кода (часто в сочетании с парным программированием), Definition of Done (чек-лист готовности элементов), итеративной разработки (адаптация кода в результате появившихся изменений или других обстоятельств) и рефакторинга (непрерывная оптимизация кода даже при отсутствии изменений в функциональности). Сторонники гибких методологий признают необходимость последовательного улучшения дизайна; под этим понимается, что в начале проекта архитектура продукта не разрабатывается в деталях (а только в самом базовом виде) и выявляется при дальнейшем развитии проекта.
Сторонники Agile-методологий считают, что инструменты – наименее важный из факторов, влияющих на успешность проекта. И тем не менее инструменты часто упоминаются и продвигаются в литературе по гибким методологиям. Опытные Agile-команды предпочитают инструменты, позволяющие осуществлять ежедневные сборки, непрерывную интеграцию и автоматическое тестирование. Команды нуждаются в мотивации, поэтому повторяющиеся скучные операции должны быть автоматизированы. Многие сторонники гибких методологий в качестве обязательного условия выдвигают наличие поддерживающей «среды обитания» в виде открытого офисного пространства, а также информационные радиаторы (к ним относятся, например, доска задач и диаграммы сгорания задач). Предназначение инструментов в контексте Agile-методологий – усиливать мотивацию, коммуникации и сотрудничество внутри команды.