Когда новые команды начинают работать по agile-методологиям, они сталкиваются с проблемами. Чаще всего это происходит, потому что они не изменили водопадных способов работы. Пример команды проекта «Музыкальный автомат» показал: недостаточно просто добавить новую практику, чтобы решить проблемы, которые вызывают конфликты и мешают изменениям. Участники проекта «Музыкальный автомат» могли утверждать, что имеют опыт гибкой разработки, но во многих отношениях они оставались водопадной командой, начавшей применять некоторые важные agile-инструменты. (Дэйв Вест из аналитического агентства Forrester Research придумал специальный термин для подобных ситуаций: Water-Scrum-Fall[12].) Другими словами, они стали самой эффективной водопадной командой.

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

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

Рис. 2.2. Отдельные члены команды стремятся добавить agile-практики в те области проекта, где уже есть успехи, поэтому улучшения происходят только в этих местах. Вот почему раздробленное видение приводит к результату «лучше-чем-ничего»

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

Как же решить эту проблему?

Ключевые моменты

Налаживание связи помогает команде лучше управлять изменениями.

Планирование в команде важнее, чем чрезмерное документирование плана и слепое следование ему.

Программные проекты были непредсказуемы и имели плохие результаты начиная с 1960-х годов, эта ситуация называлась «кризис программного обеспечения».

Многие команды пытаются «внедрять Agile», после того как им удалось улучшить с его помощью те направления, которые и так были успешны.

Выбор лучших методов приводит к результату «лучше-чем-ничего», потому что команды принципиально не изменили способ общения или работы.

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

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

Agile-манифест помогает командам видеть цели применения каждой практики

Манифест гибкой разработки программного обеспечения, более известный как Agile-манифест, написан в 2001 году группой из 17 единомышленников, которые собрались на горнолыжном курорте Snowbird Retreat неподалеку от Солт-Лейк-Сити, чтобы придумать решение, способное помочь избежать проблем при разработке программного обеспечения, с которыми они сталкивались на протяжении всей своей карьеры. После нескольких дней обсуждения был принят основной набор идей и принципов (а также придумано название Agile). Собравшиеся объединили их в один документ, меняющий образ мышления в мире разработки программного обеспечения.

Agile-манифест содержит четыре простые идеи. Приведем полный текст.

Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь непосредственно разработкой и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:

Люди и взаимодействие важнее процессов и инструментов.

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

Сотрудничество с заказчиком важнее согласования условий контракта.