Дженнифер Грин - Постигая Agile

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

То есть, не отрицая важности того, что справа, мы все-таки больше ценим то, что слева.

Понимание и эффективная работа с Agile начинается с понимания этих ценностей.

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

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