Что такое Agile? Философия, которая развивается на практике

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

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

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

Agile Предшественники

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

Модель «Планируй-Делай-Изучай-Действуй», предшественницу философии, ориентированной на итеративное улучшение, была разработана в 1930-х годах физиком и статистиком Bell Labs Уолтером Шухартом. После Второй мировой войны его протеже У. Эдвардс Деминг применил ее для обучения менеджеров Toyota. Этот метод был неотъемлемой частью разработки производственной системы Toyota, главного источника бережливого мышления с его эффективным циклом «создание-измерение-обучение».

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

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

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

Ценности Agile в теории, возникшие из этих предшественников, подтвердились в моем использовании Agile на практике с упором на итеративную разработку, совместную командную работу и точную оценку.

Что такое Agile в теории?

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

Как хорошо знают практики, передовые в распространении принципов Agile, каждая организация, стремящаяся пройти Agile-преобразование, должна найти и адаптировать подходы, которые им подходят. Я помогаю этому процессу обучения, показывая командам, как следовать ценностям и принципам манифеста, а затем черпаю вдохновение из таких фреймворков, как Scrum, Kanban и Extreme Programming (XP), чтобы реализовать их на практике.

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

1. Люди и взаимодействия важнее процессов и инструментов
2. Рабочие продукты над исчерпывающей документацией
3. Сотрудничество с клиентами в ходе переговоров по контракту
4. Реагирование на изменение вместо следования плану

Однако предостережение, которое следует за этими принципами в манифесте, часто упускается из виду: «То есть, хотя элементы справа имеют ценность, мы больше ценим элементы слева». Многие Agile-практики заканчивают тем, что игнорируют ценности справа и сосредотачиваются только на том, что слева. Результат? Противоположность слепому следованию фреймворкам, насыщенным процессами: вообще никакого процесса, что не менее проблематично.

Достижение правильного баланса между элементами справа и слева стало ключом к тому, как я руковожу Agile-трансформациями. Это также иллюстрируется подходами к управлению в Apple, Google, Amazon, Facebook и Netflix, ни одна из которых не подписалась на единую структуру Agile. Они в первую очередь воплотили принципы манифеста, следуя или изменяя части различных фреймворков в зависимости от того, что лучше всего сработало для них; в результате они адаптировались к рыночным изменениям и могут быстро поставлять новые продукты.

Что такое Agile на практике?

В следующем обзоре я изменил исходную формулировку ценностей манифеста. Изменения в семантике помогают прояснить, как я применяю ценности Agile на практике.

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

Люди важнее процессов

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

Я был встревожен, увидев, что такой менталитет привел к возникновению прибыльной «гибкой индустрии». Как объясняют основатели Agile Уорд Каннингем и Джон Керн, многие компании продают программное обеспечение, которое, как они утверждают, поможет компаниям «перейти на Agile». Но переход на Agile означает принятие философии, отказ от программного обеспечения и следование программе, которую оно предписывает.

Достижение правильного баланса заключается не в устранении процедур, а в том, чтобы найти те, которые наилучшим образом поддерживают цели разработки каждой команды. Для одного из моих клиентов, крупной корпоративной технической организации, я внедрил Disciplined Agile, подход, разработанный в IBM. Он сочетает в себе множество практик из нескольких фреймворков, включая Scrum и Kanban. Он использует итеративную разработку, но требует немного больше процессов, чем традиционный Agile, особенно на начальном этапе, потому что предназначен для заполнения пробелов, оставленных Scrum. Дисциплинированный Agile работал для этого клиента, потому что организация была очень ориентирована на процесс. Это позволило мне пойти навстречу командам, заручиться их поддержкой и убедить их принять рабочий процесс Scrum.

Я включил встречи по уточнению невыполненных работ, обзорные встречи и ежедневные скрамы, чтобы облегчить сотрудничество внутри и между командами. Уточнение невыполненной работы является частью Руководства по Scrum, а совещания по уточнению — нет. Я добавил их, чтобы обеспечить здоровую беседу о том, почему мы планировали реализовать определенные функции в предстоящих спринтах, что полезно для новичков в Agile. Я также выбрал номенклатуру «вехи» — термин, используемый в управлении проектами Waterfall, — потому что он был более знаком клиенту. Обзоры и ежедневные Scrum-взаимодействия — обычные элементы Руководства по Scrum, но я сделал их более структурированными с точки зрения расписания, продолжительности и потока.

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

Доставка программного обеспечения важнее документации

Еще одна причина, по которой я предпочитаю индивидуальные рабочие процессы Scrum или Kanban строгому соблюдению какой-либо одной структуры, заключается в том, что они дают мне возможность добавить в план минимально жизнеспособный продукт (MVP) в качестве цели. Унаследованная от Lean практика создания MVP согласуется с итеративной разработкой и стала популярной техникой среди практиков Agile. Это позволяет команде эффективно предоставлять пользователям высококачественное программное обеспечение и другие товары, а затем улучшать их на основе отзывов. Применение его как части гибридного подхода, в значительной степени основанного на Scrum или Kanban, расширило возможности моей команды по созданию продуктов, отвечающих потребностям клиентов.

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

Сотрудничество по контрактам

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

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

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

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

Адаптивность выше фреймворков

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

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

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

Я также включил понятие скорости — позднее добавление к XP, которое измеряет общую оценку усилий для всех пользовательских историй в каждой итерации продукта. Однако я использовал термин «производительность», который предпочитаю, потому что он подчеркивает, сколько работы могут выполнить члены команды, а не то, как быстро они могут выполнять задачи.

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

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

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

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

Каково будущее Agile?

Пандемия COVID-19 создала новую реальность, в которой команды больше не могли находиться в одном месте, что было предпочтительным способом работы в Agile, когда он был задуман. Однако идея о том, что так и должно оставаться, является мифом: поскольку удаленная работа стала обычным явлением, стало ясно, что тесное общение вполне возможно с помощью программного обеспечения для видеоконференций. Команды, с которыми я сейчас работаю, полностью распределены, и я провожу обучение удаленно. Некоторые команды даже предпочитают работать асинхронно, используя такие инструменты, как Notion и Loom, а также плагины Slack, такие как Standuply.

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

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