Искажая Agile

Термин Agile употребляют в двух основных значениях:

— Система ценностей или даже философия, которой следуют команды разработки.

— Общий термин для гибких подходов и методик, которые непосредственно связаны с основными ценностями Agile.

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

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

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

Важно не только использовать его методы (Doing Agile), но и внедрять его философию и культуру (Being Agile).

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

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

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

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

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

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

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

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

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

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

3. Сотрудничество с заказчиком важнее согласования условий контракта
Данный принцип подразумевает тесное сотрудничество с заказчиком и гибкую адаптацию к изменяющимся требованиям. Важно поддерживать постоянное общение с клиентом на протяжении всего проекта, получать обратную связь от него, демонстрировать ему промежуточные версии продукта и приглашать его на ключевые встречи.

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

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

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

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

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

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

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

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

Источники:

#agile #agileme #ит #управлениепроектами