Принципы гибкой методологии управления проектами Agile: почему люди важнее бюрократии

Аджайл (Agile) – философия, определенный образ мышления с системой ценностей. Сторонники аджайла верят, что создать идеальный продукт или запустить проект могут самостоятельные команды из профессионалов. Замредактора Теплицы Наталья Баранова попросила менеджера «Альфа-банка» Артема Молчанова прокомментировать основные принципы, написанные в манифесте гибкой разработки Agile.

Разработчики и практики новых подходов разработали манифест гибкой разработки программного обеспечения (Agile Manifesto) в 2001 году. В нем они обозначили 12 постулатов и заявили, что люди, продукт, готовность к изменениям и сотрудничество с заказчиками гораздо выше бюрократических документов, долгих согласований и плана.

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

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

Многие интерпретируют этот принцип так: «Люди – важно, а инструменты – неважно». Это неверно. Важны и люди, и инструменты. Но в приоритете то, как люди взаимодействуют между собой. Например, в классическом подходе работы в компаниях фокус смещен далеко не на людей. «Идем по головам, чтобы достигнуть результата» – таков принцип. Но в аджайл все наоборот: важнее развивать потенциал людей и работать сообща. В итоге сотрудники работают командами, отвечая за результат не в одиночку, а вместе.

Еще по теме: Как управлять проектом с помощью методов Agile, Scrum и Kanban

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

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

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

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

Принцип 3: «Сотрудничество с заказчиком важнее согласования условий контракта»

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

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

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

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

Еще по теме: Scrum в деталях

Принцип 4: «Готовность к изменениям важнее следования первоначальному плану»

Этот принцип зачастую интерпретируют неверно: «Что бы ни произошло – это изменения». Этим тезисом очень легко манипулировать. Допустим, владелец продукта понял, что не учел что-то важное и все пропало. Он экстренно обращается к команде и говорит: «Мы все переиграли, будем делать вот так». Команда в недоумении: «Мы же так не договаривались», а владелец пожимает плечами и аргументирует: «Ну, извините, у нас аджайл». Но этот принцип вовсе не о подобном хаосе в работе.

Раз в неделю команда собирает обратную связь от клиента и понимает, что нужно изменить, чтобы улучшить продукт. С этими пожеланиями она приходит к владельцу продукта. Начинается работа по совершенствованию. Готовность к изменениям – это когда команда понимает: «Да мы сделали не то, но мы же здравые люди, давайте поменяем нашу модель поведения и все исправим».

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

Что такое Agile: методология управления проектами

Что такое Agile

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

С моей точки зрения, общепринятый перевод полного термина Agile software development как «гибкая разработка программного обеспечения» не очень точный. Авторы термина изначально рассматривали в качестве названия вариант Adaptive, и мне он кажется немного точнее, чем Agile. 

Во-вторых, Agile — это философия, мировоззрение, выкристаллизованное из многолетнего опыта практиков. Прежде чем был сформулирован Agile-манифест, его авторы более 10 лет прорабатывали различные подходы к созданию ПО. Сейчас эти подходы известны как «гибкие», среди них — Scrum, eXtreme Programming, Crystal, Feature Driven Development и другие.

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

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

Вместо этого существует группа подходов, позволяющих реализовать ценности и принципы Agile на практике. Помимо упомянутых выше к ним относятся Nexus, LeSS, SAFe и некоторые другие.

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

Основные принципы Agile

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

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

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

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

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

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

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

Большая часть этой документации не несет также и ценности клиенту! Сначала создайте продукт, а потом документируйте его.

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

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

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

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

Конечно, оно несет определенную пользу, но приоритет отдается планированию оперативному. Как правило, горизонт детального планирования задач составляет 2-4 недели. Если все вокруг меняется часто — ваши планы тоже должны.

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

Есть еще одна базовая вещь, которую важно знать для понимания Agile — итеративно-инкрементальный подход.

Итеративно-инкрементальный подход

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

Итеративный и итеративно-инкрементальный подходы. Автор иллюстрации Jeff Patton

Разрабатывая продукт небольшими итерациями, мы получаем возможность не только раньше поставить ценность клиенту. Что гораздо важнее, мы получаем обратную связь от заказчиков. Ценно ли то, что мы делаем? Туда ли мы идем? Поставленная цель еще актуальна? Ответить на эти вопросы можно, только предоставив пользователю что-то, что он может использовать, потрогать. 

Чтобы добиться этого, мы декомпозируем наш продукт на более-менее независимые ценные элементы. В Scrum список таких элементов называется «бэклог», однако по сути это приоритизированный лист пожеланий относительно функциональности нашего продукта.

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

Закон Парето гласит, что 20% усилий дают 80% результата. Иногда даже этих 80% нашего бэклога бывает достаточно для нас или нашего заказчика.

Чем Agile отличается от Scrum

Scrum — термин из регби, по-русски — схватка. Название подходу придумал Кен Швабер, один из авторов Скрама и фанат регби. Судя по всему, количество игроков и то, как они всей командой собираются вокруг мяча, напомнило ему команду, работающую по Скраму. Кен Швабер и Джефф Сазерленд создали Скрам в 90-е (а через почти 10 лет участвовали в написании Agile-манифеста). 

Так выглядит Скрам в регби

Скрам — это процессный фреймворк, предназначенный для создания, поставки и поддержки сложных продуктов. Это цитата из официального «Руководства по Скраму», и некоторые слова в ней нуждаются в пояснении. 

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

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

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

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

Сложность продукта может происходить из:

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

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

Продукт создается итерациями, которые в Скраме называются спринтами. Это отрезки времени от одной до четырех недель, в ходе которой небольшая команда (3-9 человек) пытается создать часть продукта, которую, в идеале, можно поставить клиенту и начать приносить ему пользу. После чего команда собирает обратную связь, вносит изменения в свои планы, если они необходимы, и начинает новый спринт.

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

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

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

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

Источник: VersionOne State of Agile 13 Annual Report

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

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

Примеры проектов и применение Agile

Кейсов применения Agile в мире великое множество, и наша страна тоже не отстает. В первых рядах практиков гибких подходов в России стране идут IT-компании. За ними следуют банки и страховые компании. В основном это команды, так или иначе связанные с ИТ. Однако есть и менее типичные кейсы. 

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

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

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

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

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

Благодаря масштабируемости Скрама несколько команд могут работать на создание новых продуктов и каналов продвижения в диджитал-среде для страхования автомобиля.

Совсем большой масштаб требует дополнительных процессов, таких как Nexus, LeSS или SAFe. Известен кейс создания самолета 5-го поколения компании Saab. Модель Gripen-E создавали больше 100 команд, каждая из которых разрабатывала свой блок, узел или подсистему, в результате чего удалось добиться впечатляющих характеристик продукта при соблюдении установленных ограничений.

Инструменты Agile

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

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

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

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

Существует множество цифровых аналогов этих инструментов с впечатляющим функционалом. Однако при перемещении красочных досок и флипчартов с графиками в диджитал-пространство обычно теряется эффект «радиации» информации.

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

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

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

Плюсы Agile

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

Источник: Отчет об исследовании Agile в России 2019

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

Источник:  2015 CHAOS report from the Standish Group

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

Минусы Agile

За гибкость надо платить. В первую очередь речь идет о стоимости переработки, или «реворка». Иногда в конце итерации мы узнаем, что весь месяц бежали не в ту сторону. С одной стороны, хорошо, что всего месяц, а не весь проект. Но в любом случае приходится выбросить все, что сделали, и начать сначала. 

Некоторые организации очень беспокоят такие издержки. Их можно снизить, если создать для команды условия, в которых она сможет быстро и как можно менее болезненно ошибаться согласно неофициальному девизу Agile «Fail Fast — Fail Safe» («Ошибайся как можно раньше — ошибайся безопасно»). Однако такие структуры и среды также стоят дорого. 

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

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

Как внедрить

Agile нельзя внедрить. Agile — это трансформация процессов и культуры организации. 

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

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

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

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

Затем обучите команду. Для старта лучше всего подойдут широко распространенные подходы — Scrum или Kanban. По ним много материалов, проще найти курс для команды и нанять сотрудников, знакомых с методиками и инструментами. Выделите два или три дня для глубокого погружения участников команды и заинтересованных сторон в новый процесс. 

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

В ходе пилотного проекта должно стать ясно, насколько Agile как подход приживается в организации, какие есть ограничения и насколько целесообразно его применять. 

Следующие шаги индивидуальны — кто-то запускает еще несколько команд. Другие запускают масштабную трансформацию, а некоторые вообще отказываются от Agile.

Резюме

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

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

---

Фото на обложке: Shutterstock / Den Rise

Изображения в тексте предоставлены автором

Манифест agile все еще имеет вес?

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

Сам Манифест появился в то время, когда требовалось найти точки соприкосновения между Scrum, экстремальным программированием, Crystal Clear и другими методиками.

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

Группа Snowbird 17 хотела посмотреть, смогут ли представители разных дисциплин о чем-то договориться (о чем угодно). И к их удивлению, они смогли это сделать. Они договорились о наборе ценностей, которые определили культуру.

Вот этот набор.

Манифест разработки программного обеспечения по методологии agile

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

Благодаря проделанной работе мы смогли осознать следующее.

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

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

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

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

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

Кент Бек	Джеймс Греннинг	Роберт С. Мартин
Майк Бидл	Джим Хайсмит	Стив Меллор
Эри ван Беннекум	Эндрю Хант	Кен Швабер
Алистер Кокберн	Рон Джефрис	Джефф Сазерленд
Уорд Каннингем	Джон Керн	Дейв Томас
Мартин Фаулер	Брайан Марик

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

Это все. С тех пор веб-сайт с Манифестом Agile практически не изменился (а может, не менялся вовсе), чего не скажешь о мире вокруг Agile.

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

Что такое Agile-подход и зачем он нужен бизнесу? — статья в блоге ScrumTrek

Agile («аджайл») — слово, которое последнее время звучит из каждого утюга. Но что такое Agile и, главное, зачем этот Agile нужен?

Если открыть толковый словарь, например, Оксфордский, то можно прочитать там, как минимум, два определения:

1. Able to move quickly and easily.
2. Able to think and understand quickly.

То есть, чтобы быть agile, надо уметь быстро и легко двигаться и быстро соображать. Кажется, довольно полезные качества, особенно в бизнесе. Быстро соображать и быстро реагировать — это именно то, что доктор прописал, для нашего времени, иначе просто не выжить: конкуренты сожрут. В мире всё меньше отраслей, где этих конкурентов, нет. Да ещё скорость копирования практически лишает возможности вывести продукт на рынок и почивать на лаврах. Без способности быстро адаптироваться к изменениям, которую даёт так называемая «методология Agile», выживать всё сложнее.

Я не случайно беру выражение «методология Agile» в кавычки, потому что его можно часто услышать, но оно не совсем верное. Если не вдаваться в технические детали, то Agile — это не методология, а собирательное название различных методик и подходов к управлению, которые:

1. Фокусируют команду на нуждах и целях клиентов.
2. Упрощают оргструктуру и процессы.
3. Предлагают работу короткими циклами.
4. Активно используют обратную связь.
5. Предполагают повышение полномочий сотрудников.
6. Имеют в своей основе гуманистический подход.
7. Не являются конечным состоянием, а, скорее, образом мышления и жизни.

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

Фокусировка на нуждах и целях клиентов

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

Самое главное, что фокусировка на клиенте при Agile-подходе появляется не в одной только голове владельца бизнеса (она там и так уже есть), а у всех, кто работает над созданием продукта или сервиса. Каждый участник процесса должен понимать, кто клиент, чего он хочет, какие его проблемы мы решаем своим продуктом, что он любит, чего боится и так далее. Такая всеобщая фокусировка позволяет создавать на порядок более качественные решения. Я неоднократно сталкивался с ситуацией, когда люди, раньше отвечавшие за какой-то маленький кусочек работы, поняв цели клиента, начинали выдавать замечательные идеи, а люди, которые отвечают за разработку продукта, с удивлением за ними записывали. Или — как на групповых сессиях проработки продукта подобные идеи оттачиваются разными людьми и дополняют друг друга, из просто хороших превращаясь в отличные. И, конечно, как они потом реализуются.

«Инструменты работы» в данном случае — это непродолжительные по времени, но насыщенные сессии (встречи) всех участников работы или ключевого большинства, где происходит генерация и тестирование различных идей. Эти же встречи служат для выравнивания понимания и фокусировки: все участники встречи на выходе понимают, что они делают, зачем, и почему это важно для клиента. А демократичный формат воркшопа, в отличие от скучных презентаций, гарантирует большее включение и мотивацию всех участников.

Примеры подобных инструментов — Lean Canvas, Impact Mapping, User Story Mapping и другие принятые в Agile методы описания гипотез и процессов.

Упрощение оргструктуры и процессов

Один из краеугольных камней Agile — это предельная простота. И оргструктура организации, и процессы, по которым работают люди, и правила должны быть настолько простыми, насколько это возможно. Это позволит людям сфокусироваться на своей работе, на ценности, которую они создают, а не на соблюдении регламентов и правил. Прекрасные примеры такого подхода можно найти во множестве команд, работающих по Scrum — самому популярному способу организации рабочего процесса в Agile. Фактически, все договорённости и правила команды размером до 9 человек, текущие задачи на пару недель, цели, а также стратегические планы легко могут поместиться на 2-3 листа бумаги А0. На одном листе может быть так называемый «бэклог спринта», перечень всего, что команда собирается сделать в ближайшую итерацию. Если повесить такой в помещении, где идёт работа, можно избавить себя от необходимости всё это запоминать. То же самое касается и процессов. Скажем, в Скраме место и время проведения всех встреч жестко фиксируются. Любой участник точно знает, что, например, в понедельник в 10-00 будет планирование ближайшей итерации, а в пятницу в 17-30 — встреча по улучшению процесса работы.

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

Примеры упрощения (и уплощения, но это тема отдельного разговора) в Agile — Scrum, Nexus, LeSS (Large-Scale Scrum, или Скрам на больших масштабах), а также сам Agile-манифест.

Работа короткими циклами

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

Чтобы подобного избежать, применяется так называемый итеративно-инкрементальный подход, когда:

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

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

Ещё одно преимущество такого подхода, помимо раннего выхода на рынок и внесения изменений на ранних стадиях работы, — это возможность более точно измерять прогресс. Мы не просто «сделали 15% всей работы», что довольно абстрактно. Мы «сделали 15% функционала», который уже работает.

Все процессные подходы в Agile имеют короткие циклы, будь то упомянутые ранее Scrum, Nexus, LeSS, SAFe или XP, плюс необходимость работы такими циклами упомянута и в самом манифесте Agile.

Активное, системное использование обратной связи

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

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

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

Примеры, опять-таки, есть везде: ретроспективные встречи в Scrum, Kanban, Nexus и LeSS, циклы I&A в SAFe, подход к созданию продуктов Design Thinking, циклы обратной связи в DevOps и т.д.

Повышение полномочий сотрудников

Зачем давать больше полномочий, когда можно дать бумажку с инструкцией? Есть, как минимум, три причины это делать.

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

Во-вторых, давая больше полномочий, мы даем больше ответственности, и люди вынуждены учиться принимать решения самостоятельно и, главное, нести за них ответственность. Это долго, сложно, но оно того стоит. Работа не остановится, если самоорганизованная команда столкнется с незнакомой, неизвестной ранее проблемой. Да и кто будет спорить, что на работе от зрелых и ответственных, взрослых людей больше пользы, чем от больших детей, неспособных думать самостоятельно?

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

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

Гуманистический подход

Зачем относиться к людям по-человечески? То есть, моральная сторона дела ясна, а какую пользу это принесёт владельцу предприятия?

Ответ довольно простой. Если создание того, что вы продаёте, не требует умственного труда, а только механический действий — можете не заморачиваться. Просто платите соразмерно сделанной работе, и всё. Но как только в дело вступает мозг работников — придётся считаться с принципами мотивации умственного труда. А они говорят, что для людей важны возможность самореализации, повышения своего мастерства, принесения чего-то ценного в мир, самостоятельности в решениях и ещё ряда факторов. И человек мотивированный (не путать с человеком простимулированным!) будет вкладываться в работу сильнее, и результат будет качественнее и быстрее. Да и в целом, приятная обстановка на работе добавляет желания туда приходить и работать — с этим тоже вряд ли кто поспорит.

И, что приятно, если копнуть в тот же Скрам, то окажется, что все ключевые факторы мотивации работника умственного и/или творческого труда в него уже включены. В каждой итерации («спринте») мы ставим цель, которой хотим достичь; нам даётся возможность решать, как именно достигать цели; в конце мы смотрим, насколько мы стали лучше (или хуже) работать, чем раньше; видим людей, которые заинтересованы в продукте, и их эмоции от знакомства с ним. Особенно хорошо, если эти эмоции положительные.

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

Agile — это не конечное состояние, а образ мышления и жизни

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

И если всё удалось: люди в компании понимают и разделяют ценности и принципы Agile, работают согласно им, — тогда менеджменту не придётся «тащить» на себе любые изменения или «пинать» работников, чтобы они начали что-то делать по-другому. Предприятие станет единым организмом, а работа будет приносить больше удовольствия.
А там, где больше удовольствия от работы, и результат выше. Это касается не только специалистов, но и менеджмента, причём в ещё большей степени.

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

Agile методологии управления проектами

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

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

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

Вы наверняка слышали такие термины как SCRUM, Crystal, DSDN, Extreme programming – все это подмножества множества Agile, есть и другие agile-методики, которые упоминаются не так часто.

Agile противопоставляют в основном классическому менеджменту проектов, а не методологиям разработки программного обеспечения.

Как возник Agile

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

На тот момент в ходу был метод «водопада» (waterfall) – последовательной разработки программного продукта из шести стадий:

1. Формирование системных и программных требований.
2. Анализ требований, существующих процессов и т.п.
3. Дизайн архитектуры программного обеспечения.
4. Непосредственно написание программного кода.
5. Тестирование и исправление ошибок, выявленных тестерами.
6. Внедрение и исправление ошибок, выявленных пользователями.

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

Но в конце 70-х годов особенности метода последовательной разработки стали ее недостатками: отсутствие гибкости в ответ на изменение условий; жесткость в отношении этапов проекта; зарегламентированность / бюрократия – все это мешало разработке массового программного обеспечения. Особенно в условиях растущей конкуренции, когда вопросы скорости предоставления готового продукта, оптимизации затрат на единицу выпуска выходили на первый план.

Гибкие методы появлялись органично в ответ на условия конкуренции:

• если нет определенности в отношении финальных параметров продукта, не нужны жесткие спецификации – используем список пожеланий к продукту (back-log), который может меняться и дополняться по мере развития проекта;
• если данные о требованиях рынка противоречивы, и единственное решение – как можно быстрее показать конечному клиенту или начать продавать, то делим продукт на части, которые сразу можно использовать или выпускаем MVP – минимальный жизнеспособный продукт (minimum viable product).
• если сроки «жмут», надо поставить график перед лицом, а для наглядности заменить его доской «Канбан» (см. также про бережливое производство). И так далее.

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

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

О принципах Agile четко и ясно

Все основные принципы гибкой разработки изложены в одном документе – Манифесте (Agile Manifesto, 2001). Выше я уже несколько раз упоминал отдельные принципы, лежащие в методологиях объединяемых Agile.

Основные постулаты:

1. Люди и взаимодействие важнее процессов и инструментов – акцент на людях и отношениях между ними, как основном факторе успешности проекта. Люди руководят и применяют необходимые им процессы и инструменты, а не работают под управлением заранее принятого регламента. Именно поэтому agile-методики предполагают отбор в команду мотивированных профессионалов, с универсальными навыками. Тогда не потребуется внедрять изощренные методы поощрений и штрафов, люди смогут подменять другу друга, участвовать в дискуссии о продукте осознанно и эффективно. Взаимодействие между членами команды может строиться с помощью любых удобных инструментов, но не документов, регламентов и инструкций.
2. Работающий продукт важнее исчерпывающей документации – менять, адаптировать, корректировать легче то, что уже существует и работает, а не то, что подробно и исчерпывающе описано в бумагах. Сначала надо сделать что-то простое и работающее, чтобы затем, оценив и апробировав сделанное, внести коррективы или отказаться от реализованного в пользу иного варианта исполнения. Но в итоге либо продукт есть и работает (пусть и требует корректировок, дополнений и доработки), либо есть проверенная гипотеза, от которой надо отказаться. В противном случае в большинстве случаев будет реализован проект, точно соответствующий описанию на бумаге, но не соответствующий рынку, производству, и главное реальным нуждам клиента.
3. Сотрудничество с заказчиком важнее согласований условий контракта – в сложившейся реальности заказчик – а им может быть и соответствующее подразделение внутри компании – не всегда может четко сформулировать требования к продукту, зачастую у него есть только профиль клиента и проблема, с которой тот сталкивается. Заказчик может оценить реализованный продукт с точки зрения соответствия его ожиданиям, но не формализовать их. Ему легче потратить время и деньги на версии продукта, чем на всестороннее и исчерпывающее описание, причем такое описание может оказаться более дорогим, трудоемким и затратным по времени, чем гибкая разработка. Методом оптимизации в данном случае как раз и будет сотрудничество с заказчиком, вовлечение его в работу проектной команды.
4. Готовность к изменениям важнее следованию первоначальному плану – это, наверное, самый противоречивый постулат. С одной стороны легче и проще менять все по ходу реализации, с другой — процесс такой разработки может затянуться на неконтролируемое время и привести к неожидаемым результатам.

Ключевые принципы гибкой разработки, изложенные в Манифесте:

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

   На примере калькулятора для анализа проекта:

   • по завершении первого спринта вычисляется NPV в Microsoft Excel – все основные формулы работают, ошибок нет, выдается только финальная цифра – рассчитанный NPV;
   • по завершении второго спринта NPV рассчитывается также как по итогам первого спринта, но добавляется функциональность – комментарий о полученном значении, расчет IRR и других критериев – для более полной картины;
   • по завершении третьего спринта на основе разработанной в первых двух спринтах логики и формул, выверенных и согласованных с заказчиков текстов готовится десктопная версия продукта;
   • по завершению четвертого спринта готовится мобильная версия продукта и… вуаля! Продукт готов к использованию для задач заказчика.
2. Изменения требований приветствуются. Разработка продукта ведется в быстроменяющейся конкурентной среде, когда по завершении цикла разработки уже может измениться рынок, например, вышел аналог. Тогда, чтобы не выкинуть в мусорную корзину реализованный проект, его дорабатывают, кстати, можно использовать опыт уже вышедшего на рынок конкурента. Поэтому в рамках гибкого подхода изменения требований продуктов даже в конце разработки – приемлемы и приветствуется.
3. Частая поставка рабочего программного продукта. Важность этого принципа все в том же – мир быстро меняется и чем короче цикл поставки, тем точнее финальный продукт будет соответствовать ожиданиям.
4. Погружение заказчика в работу над проектом на протяжении всего времени его реализации. Заказчик в этом случае является единственным участником команды, носителем знания, «как надо», соответственно его заключение о соответствии продукта ожиданиям и его удовлетворение от результата – ключевой критерий. Чем чаще ожидания заказчика сопоставляются с работой команды проекта, тем, естественно, выше соответствие ожиданий и результата.
5. Проектом занимаются мотивированные личности, которые обеспечены соответствующими условиями работы, поддержкой и доверием. Этим принципом проблемы мотивации выводятся за рамки работы над проектом. Предполагается, что на этапе формирования команды, необходимо отбирать только мотивированных профессионалов, самодостаточных личностей, которых не надо подгонять, уговаривать и т.п. Задача сведется только к созданию условий, не препятствующих реализации их потенциала в этом проекте: инструменты связи, возможности для взаимодействия, оборудование и материалы и др.
6. Рекомендуемый метод коммуникации – лицом к лицу. Это спорный принцип в цифровую эпоху, когда многие компании развивают сетевое взаимодействие и внедряют удаленную работу в свои процессы. При этом личное взаимодействие имеет ряд преимуществ, которых нет у других видов коммуникации: например, скорость решения вопросов, невербальные сигналы (эмоции, жесты), мотивация (можно похвалить, выделить, поставить «на место»). В любом случае манифест акцентирует на этом внимание и заявляет, как один из ключевых принципов.
7. Работающее программное обеспечение – лучший измеритель прогресса. Перенося этот принцип на более общую систему координат, работающая версия продукта — лучший критерий успешности и прогресса проекта. В большом числе случаев этот принцип реализуем и понятен, а там, где не применим Agile.
8. Разработчики, а также их куратор и заказчик должны быть готовы сохранять заданный темп в разработке в течение не определенного (читай — неограниченного) времени. Надо понимать, что в такой парадигме срок разработки финальной версии продукта не известен, более того, финальной версии может и не быть, что мы видим на примере постоянно шлифуемых и дорабатываемых версий десктопного программного обеспечения и мобильных приложений.
9. Краеугольным камнем Agile-разработки заявляется стремление к техническому совершенству и качеству планирования спринтов. Этот принцип призван сбалансировать возможный негативный эффект на качество разработки от других принципов, например, частой поставки рабочего продукта. Можно разными методами добиваться частой поставки в условиях отсутствия или недостатка спецификаций продукта, например, использовать готовый, но некачественный код разработанный «индийскими программистами» и пренебречь тестированием. Личные качества, профессионализм разработчиков и коллективная ответственность – заложенные в принципе «стремления к техническому совершенству» требуют более высокого уровня ответственности.
10. Простота и минимизация лишней работы. Этот принцип надо бы применять во всех проектах, но в качестве ключевого принципа он заложен только в Agile-методиках. Приоритет отдается тому, что делается быстро с минимальными затратами. Отказываемся от ненужных работ как в процессах, так и в отношении продукта, например, консалтинговая компания обычно готовит многостраничную презентацию по выполненным работам и предполагаемым шагам, но если клиент интегрирован в команду, то ему формальная бумага не нужна, ему важнее то, что уже идет в работу – те самые два-три слайда, которые уже готовы для финальной презентации. В отношении продукта – можно стремиться реализовать все задумки в отношении функционала сразу до первого релиза, однако так уже никто не делает, в каждой итерации продукт совершенствует в соответствии с требованиями рынка, что может подразумевать как добавление нового функционала, так и удаление каких-то фич, не «принятых» клиентами.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. Речь идет не об анархии, а о высокой внутренней дисциплине в команде, четком распределении ролей и высоком уровне профессионализма каждого участника. Если вы не можете самоорганизовываться – не работайте в концепции Agile.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы. Этот принцип подчеркивает, что вся полнота ответственности за проект и его продукт лежит на всех членах команды, никто со стороны не вносит корректив и не анализирует эффективность – все делают участники внутри своего коллектива в интересах проекта и результата.

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

Области применения Agile

Agile в своем максимальном объеме применим и эффективен при создании продуктов, которых:

• не существовало ранее,
• у которых нет аналогов;
• которые представляют собой технологически сложный или комплексный продукт.

Таким образом, применение agile-методов оправданно в следующих сферах бизнеса:

1. Программное обеспечение для массового сегмента, в том числе мобильные приложения, игры и т.п.
2. Стартап-проекты – это идеальная почва для внедрения гибких методологий.
3. Интернет-порталы и СМИ.
4. Медицинские проекты – тело человека до сих пор в значительной мере «терра инкогнита», что создает высокую долю неопределенности в медицине.
5. Образовательные продукты и проекты. Если мы говорим о чем-то новом, а не о компиляции старых методов и практик, то образовательные проекты – стартапы на неизведанной территории, все ищут новые методы цифровой эпохи на замену старым технологиям индустриального мира.
6. Консалтинг – любой проект в этой сфере требует применения большинства принципов Agile Manifesto. McKinsey однозначно используют методику соответствующую указанным принципам.
7. Разработка финансовых и страховых продуктов (индустрия финтех), так как финансовые компании сегодня, это в большой степени ИТ-компании, а финансовый продукт уже стал в значительной степени ИТ-продуктом или применяет результаты работы ИТ-проектов/продуктов.

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

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

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

Что такое Agile и подойдет ли он вашей компании

Agile-манифест базируется на четырех главных ценностях:

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

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

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

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

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

3. Сотрудничество с заказчиком важнее соблюдения формальных условий.

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

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

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

Agile не исчерпывается четырьмя ценностями [1]. В манифесте есть также 12 принципов, которые уточняют и дополняют их. Их можно свести к следующему:

• Главная цель — удовлетворение потребностей заказчика. Все процессы и задачи меняются и подстраиваются под них.
• Разработчики и представители заказчика должны работать вместе ежедневно, обмениваясь идеями и полезной информацией.
• Каждый участник команды должен быть хорошо замотивирован: комфортными условиями, позитивными откликами, финансовыми поощрениями.
• Изменения допустимы на любом этапе, даже перед самым выпуском. При этом за каждую итерацию (от двух недель до двух месяцев) вы должны выпускать рабочий продукт.
• Все должны стремиться к максимальной простоте и самоорганизации.

Agile, таким образом, — это система ценностей или даже философия ведения бизнеса. Она помогает сосредоточиться на главном, избавиться от ненужных формальностей и создавать рабочий продукт быстрее и эффективнее. Чтобы воплотить эти ценности на практике, используют конкретные методы. Согласно исследованию Agile в России [2], самые популярные из них — Scrum и Kanban.

Что такое методология Agile, как внедрить Agile и почему это нужно сделать

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

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

Agile-подход и принципы Agile

Перевод с английского слова «эджайл» — это «подвижный», «проворный». Управление проектами по методологии Agile простыми словами — это организация работы над проектом, которая не предполагает жесткого долгосрочного планирования. Команда приближается к цели небольшими шагами, которые еще называются «итерации».

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

Ценности Agile. Ключевые инсайты:

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

Agile-манифест содержит ключевые инсайты создателей и 12 принципов Agile для разработки программного обеспечения. В манифесте нет однозначных инструкций, как организовать работу по методу Agile. Например, там нет никаких упоминаний о мотивации сотрудников. Однако основные положения Agile-манифеста стали ключевыми для этого семейства гибких методологий, позволяющих легко управлять различными проектами. Самые известные из них — это SCRUM и Kanban.

Фреймворк SCRUM. Отличие Agile от SCRUM

Часто люди затрудняются ответить, в чем же заключается отличие Agile от SCRUM. На самом деле все просто. SCRUM — это конкретный метод реализации Agile-подхода, фреймворк, который соответствует ценностям Agile и использует в работе метод Agile. Ключевую роль в SCRUM играет agile-команда: это команда «универсальных солдат», которые могут работать над разными проектами. Помимо специалистов в команде есть product manager, владелец продукта, и scrum master. Product manager следит за тем, чтобы проект отвечал потребностям заказчика и решал его задачи. Scrum master же координирует работу команды, в том числе отвечает за мотивацию команды, решает рутинные задачи.

Гибкий цикл разработки по фреймворку SCRUM делится на равные отрезки времени, которые принято называть «спринтами». Это может быть как неделя, так и месяц. Перед спринтом команда и scrum master определяют задачи, которые необходимо решить для реализации проекта, а в конце спринта — подводят итоги. С помощью спринтов scrum-мастеру легко контролировать эффективность команды, находить недочеты в работе и определять способы мотивации.

Kanban. Отличия Kanban от SCRUM

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

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

В отличие от менеджмента по SCRUM, в модели Kanban главная метрика эффективности — среднее время решения задачи. В этой гибкой методологии очень важно отслеживать, на какой стадии выполнения находится каждая задача. Как правило, основные стадии выполнения задачи фиксируют на kanban-доске, чтобы руководителю и сотрудникам было одинаково удобно контролировать прогресс.

 

Task	Step 1	Step 2	Step 3	Step 4	Status
	Max 2	Max 3	Max 3	Max 2
K
L	I	F	C	A
M	J	G	D	B
N		H	E
O
P

Agile или Waterfall. Что выбрать?

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

Agile

+	—
Работа строится так, чтобы клиент быстро получил готовый продукт	Итоговую стоимость проекта при работе по методологии Agile зачастую сложно подсчитать
В работу над проектом вовлечены не только исполнители, но и организаторы, заказчики	Высокие требования к квалификации специалистов, которые работают над проектом, зачастую возникает необходимость их обучения. Как следствие, высокая стоимость работы таких специалистов
Возможность гибко реагировать на изменения	Невозможность «механически» применять методологию Agile: всегда нужно адаптировать ее под особенности конкретной команды
Приоритет — создание рабочей модели продукта	При отсутствии необходимого опыта команда может потратить слишком много времени на работу над незначительными улучшениями и не успеть сделать основную работу по проекту вовремя

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

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

Waterfall

+	—
Легко оценить итоговую стоимость проекта	Итоговая стоимость работ по проекту может увеличиться, но маловероятно, что она уменьшится
Привычная и понятная модель работы	Работу нельзя подстроить под непредвиденные обстоятельства. В крайнем случае — можно сэкономить время на стадии тестирования продукта, отказавшись от нее
Привычные формы отчетности по проекту	Невозможно тестировать продукт в ходе работы. Тестирование можно организовать, только когда проект фактически завершен
Задачи определены с момента запуска проекта	В продукт невозможно внести изменения в процессе разработки, даже если разработчик понимает, как продукт можно улучшить

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

Применение Agile в управлении бизнесом и маркетинге

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

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

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

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

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

Новый манифест Agile-маркетинга. Философия подхода:

1. Точные исследования, а не мнения и предубеждения.
2. Кооперация, направленная на соблюдение интересов клиента, а не иерархия.
3. Итерация и адаптация, а не сложное планирование в рекламных кампаниях.
4. Исследование клиентов, а не статистическое прогнозирование.
5. Гибкое, а не жесткое планирование.
6. Адаптация к изменениям, а не четкое следование плану.
7. Множество небольших экспериментов, а не один большой.

Внедрение Agile

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

1. Agile-коуч. Выбрать подходящего agile-коуча для компании может оказаться непростой задачей. Во-первых, без знаний по Agile сложно оценить квалификацию коуча и качество его работы. Зачастую тот, кого нанимают как agile-коуча, начинает выполнять роль scrum-мастера. Без предварительного обучения команды такой способ может только навредить компании и внести смуту в рабочие процессы.
2. Тренинги Agile для руководителя. Сначала руководитель проходит обучение по Agile, а затем он обучает команду. Главный минус такого метода в том, что основная нагрузка по внедрению Agile ложится на плечи руководителя, при этом он продолжает решать свои повседневные задачи.
3. Курсы Agile. Обучение на курсах Agile дает возможность познакомить всю команду с культурой и методологией Agile. Главное — выбирать качественные курсы, которые славятся положительными отзывами других студентов. Например, с курсом Lectera «Эффективное управление бизнесом по методологии Agile» руководитель в кратчайшие сроки освоит принципы работы по Agile, а при покупке тарифа Lectera Corp — сразу сможет организовать обучение для своих сотрудников. Преимущество курсов от Lectera в том, что основной упор в них делается на практику: студенты могут отработать полученные знания с помощью прилагающихся кейсов и упражнений.

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

Книги, посвященные Agile, его технологии и философии:

1. Agile-манифест разработки программного обеспечения.
2. Элияху Голдратт, Джефф Кокс. «Цель: процесс непрерывного совершенствования».
3. Джефф Сазерленд. «SCRUM. Революционный метод управления проектами».
4. Хенрик Книберг. «SCRUM и XP: заметки с передовой».
5. Дэвид Андерсон. «Канбан. Альтернативный путь в Agile».
6. Эндрю Стеллман, Дженнифер Грин. «Постигая Agile. Ценности, принципы, методологии».

Главное в статье

1. Agile — семейство методологий. В методологиях Agile работа над проектом выстраивается так, чтобы гибко реагировать на изменения.
2. SCRUM — фреймворк Agile. В SCRUM работа над задачей разбивается на равные промежутки времени — спринты. Их анализ позволяет отслеживать эффективность работы.
3. Kanban — Agile-методология. Основной показатель эффективности для нее — скорость решения задач. Чтобы отслеживать прогресс, стадии работы над каждой задачей визуализируют на kanban-доске.
4. SCRUM и Waterfall — две самые популярные методологии для разработки программного обеспечения. SCRUM лучше подходит для зрелых команд.
5. Гибкие методологии идеально подходят для областей, в которых нужно быстро реагировать на изменения рынка, например для программирования и маркетинга.
6. Для эффективной работы по Agile необходимо качественно обучить команду. Удобнее всего это делать на Agile-курсах.

Что такое гибкие принципы? Определение, примеры и часто задаваемые вопросы

Что такое гибкие принципы?

💬

Определение принципов гибкости

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

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

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

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

Преимущества принципов Agile

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

Получите нашу электронную книгу Mastering Prioritization eBook

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

Получить электронную книгу

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

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

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

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

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

Примеры Agile-принципов

Вот 12 Agile-принципов:

1. «Нашим высшим приоритетом является удовлетворение потребностей клиента посредством своевременной и непрерывной поставки ценного программного обеспечения».

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

2.«Приветствуем меняющиеся требования даже на поздних стадиях разработки. Гибкие процессы используют изменения для конкурентного преимущества клиента ».

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

3. «Часто доставляйте работающее программное обеспечение, от пары недель до пары месяцев, с предпочтением более коротких сроков».

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

4. «Деловые люди и разработчики должны ежедневно работать вместе на протяжении всего проекта».

Принципы гибкости объединяют различные отделы, уделяя приоритетное внимание регулярному сотрудничеству и общению для обмена информацией / ресурсами.

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

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

6. «Самый действенный и действенный метод передачи информации команде разработчиков и внутри нее — это личное общение».

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

7. «Работающее программное обеспечение — главный критерий прогресса».

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

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

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

9. «Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность.”

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

10. «Простота — искусство максимизировать объем невыполненной работы — очень важна».

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

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

12. «Команда регулярно размышляет о том, как стать более эффективной, а затем соответствующим образом настраивает и корректирует свое поведение».

Команды следует поощрять к тому, чтобы они размышляли о своем прогрессе и вносили изменения в продукт, а не слепо двигаться вперед.

Когда вам нужны гибкие принципы?

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

Объяснение 12 принципов гибкого управления проектами

Согласно годовому отчету PMI Pulse of the Profession, 48% проектов не завершаются в запланированные сроки, 43% превышают первоначальный бюджет и 31% проектов не соответствуют первоначальным целям и бизнес-намерениям.Это звучит не очень оптимистично.

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

12 принципов гибкости

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

# 1 Удовлетворение клиентов ранней и непрерывной доставкой

Исходная формулировка первого из принципов Agile гласит: « Наш главный приоритет — удовлетворить клиента за счет своевременной и непрерывной поставки ценного программного обеспечения. » . Тем не менее, это прекрасно применимо в областях, не связанных с разработкой программного обеспечения.

Как видите, удовлетворенность клиентов находится на вершине 12 принципов. Ранняя и непрерывная доставка увеличивает вероятность удовлетворения требований клиентов и способствует более быстрой окупаемости инвестиций.

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

# 2 Добро пожаловать! Изменение требований даже на поздней стадии проекта

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

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

# 3 Доставляйте ценность часто

Третий принцип управления проектами Agile изначально гласит: «поставлять работающее программное обеспечение часто, от пары недель до пары месяцев, с предпочтением более коротких временных рамок» . Его основная цель — уменьшить размеры пакетов, которые вы используете для обработки работы.

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

# 4 Разбейте свой проект

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

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

10 лет опыта использования канбана в 1 бесплатной книге:

Руководство по Канбану для менеджера проекта

# 5 Строить проекты вокруг мотивированных людей

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

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

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

# 6 Самый эффективный способ общения — лицом к лицу

«Самый действенный и действенный метод передачи информации команде разработчиков и внутри нее — это личное общение».

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

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

# 7 Работающее программное обеспечение — главный критерий прогресса

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

Если результат вашей работы не такой, как ожидает ваш клиент, у вас проблемы

# 8 Поддержание устойчивого рабочего темпа

Точная формулировка этого принципа: «Гибкие процессы способствуют устойчивому развитию. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп неограниченное время».

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

# 9 Непрерывное совершенство повышает гибкость

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

В результате изменения в коде с меньшей вероятностью повлияют на ошибки и сбои.

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

# 10 Главное в простоте

Исходное содержание этого принципа может немного сбивать с толку, поскольку он заявляет: « Простота — искусство максимального увеличения объема незавершенной работы — имеет важное значение» . Тем не менее, это очень практично.

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

# 11 Самоорганизующиеся команды создают наибольшую ценность

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

Если вам нужно подтолкнуть свою команду и «двигать ее вперед», возможно, вы не готовы к Agile или вам нужно внести некоторые изменения в свой стиль руководства.

# 12 Регулярно размышляйте и корректируйте свой стиль работы для повышения эффективности

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

Делая это, вы сможете экспериментировать и постоянно улучшать свою производительность. Если дела идут не так, как вы планировали, вы можете обсудить, что пошло не так, и приспосабливаться, чтобы вернуться в нужное русло.

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

Удачи!

Попробовать Kanbanize бесплатно

В итоге

Реализация 12 принципов Agile поможет вашей организации:

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

12 принципов Agile: что они собой представляют и имеют ли они значение?

Последнее обновление: 3 июня 2021 г.
Блог Plutora — Agile Release Management Время чтения 11 минут

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

Ранняя и непрерывная поставка ценного программного обеспечения

Как гласит первый принцип: «Нашим наивысшим приоритетом является удовлетворение потребностей клиента за счет своевременной и непрерывной поставки ценного программного обеспечения».

Обычно мы разрабатываем программное обеспечение на чужое время и деньги, чтобы помочь им каким-то образом. Если мы будем ждать слишком долго, чтобы доставить товар, он, вероятно, не удовлетворит покупателя. Сейчас это еще более актуально, чем в 2001 году. Не только важно иметь раннюю обратную связь и получать ее постоянно на протяжении всего проекта, клиенты ожидают быстрой доставки .И каждая поставка должна приносить пользу покупателю. Например, клиента не волнует, что вы отредактировали страницу входа. Она заботится о том, что теперь позволяет ей войти в свою учетную запись Google.

Устранение разрыва между DevOps и Agile с помощью Plutora

Управление зависимостями между методологиями Agile, DevOps и Waterfall может быть проблемой.Plutora обеспечивает среду для совместной работы, в которой команды могут быстро двигаться.

Учить больше

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

Принять изменение

Второй принцип гласит: «Приветствуйте меняющиеся требования даже на поздних стадиях разработки.Гибкие процессы используют изменения для конкурентного преимущества клиента ».

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

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

Частые поставки

Следующий принцип: «Доставляйте работающее программное обеспечение часто, от пары недель до пары месяцев, с предпочтением более коротких сроков.”

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

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

Бизнес и разработчики вместе

Другой принцип гласит: «Деловые люди и разработчики должны ежедневно работать вместе на протяжении всего проекта.”

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

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

Мотивированные лица

Также есть «Создавайте проекты вокруг мотивированных людей. Обеспечьте им среду и поддержку, в которых они нуждаются, и доверьте им выполнение работы.”

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

Если вы строите свои проекты вокруг людей, которые не мотивированы или были демотивированы из-за отсутствия доверия или поддержки, ваш проект вряд ли будет успешным.Хуже того, умным разработчикам не составит труда найти лучшую работу.

Личный разговор

И еще есть принцип, гласящий: «Самый действенный и действенный метод передачи информации для разработки и внутри нее — это личное общение».

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

Следующая диаграмма из книги Алистера Кокберна «Гибкая разработка программного обеспечения» показывает, насколько эффективны различные формы коммуникации:

С 2001 года наши методы работы кардинально изменились. Во многих организациях есть люди, которые работают удаленно, даже в других часовых поясах. Такие технологии, как трекеры проблем и Slack, создают способы асинхронной связи, а такие инструменты, как Skype и Hangouts, позволяют нам вести удаленные личные переговоры.Это никогда не будет на 100% похожим на реальное взаимодействие, но, возможно, достаточно хорошо. Команды по всему миру доказывают, что они могут быть успешными и гибкими, даже не видя друг друга в реальной жизни.

Рабочее программное обеспечение

Один из принципов гласит: «Работающее программное обеспечение — это основная мера прогресса».

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

Сегодня мы часто идем дальше. Если работающее программное обеспечение не было отправлено, оно не закончено и, следовательно, не было достигнуто никакого прогресса. Невыпущенное программное обеспечение — это инвентарь. А запасы — это стоимость, а не доход или ценность.

Устойчивое развитие

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

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

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

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

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

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

Техническое совершенство

Есть еще одна пословица: «Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность».

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

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

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

Это не означает, что нам нужны большие теоретические разработки, прежде чем мы начнем писать код.Хороший дизайн может появиться по мере развития программного обеспечения. Но разработчикам нужно найти время и быть достаточно ответственными, чтобы это сделать.

Простота

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

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

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

самоорганизующиеся команды

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

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

Команды должны научиться самоорганизовывать все аспекты разработки программного обеспечения: они должны собирать требования, общаясь с бизнесом, писать качественное программное обеспечение, организовывать свою работу и т.д. .

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

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

Регулярное отражение и регулировка

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

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

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

Все они имеют значение

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

Питер Морлион

Питер — увлеченный программист, который помогает людям и компаниям улучшать качество своего кода, особенно в устаревших кодовых базах.Он твердо уверен, что лучшие отраслевые практики имеют неоценимое значение для достижения этой цели, и его специальности включают принципы TDD, DI и SOLID. https://www.petermorlion.com/

Agile Manifesto | 4 ценности и 12 принципов Agile: объяснение

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

Настоящий документ, состоящий из ценностей и принципов гибкого подхода, был разработан в 2001 году группой из 17 инженеров-программистов на горнолыжном курорте в Юте. «Agile Alliance» был создан, чтобы бросить вызов статус-кво и полностью изменить подход к решению проблем и управлению проектами.

То, что начиналось как руководство по разработке программного обеспечения, теперь стало общепринятой философией управления проектами.Сегодня Agile-процессы используются не только командами разработчиков программного обеспечения, но и практически всеми функциями бизнеса. Многие из первоначальных членов Agile Alliance продолжили разработку других популярных фреймворков, таких как методология Scrum, методология Kanban, Crystal и Integrated Agile на основе методологии Agile.

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

Устали пользоваться Monday.com?

Узнайте, почему понедельник неэффективен для управления проектами и почему вам нужна альтернатива понедельника

Почему была разработана методология Agile?

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

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

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

4 значения Agile Manifesto

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

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

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

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

3. Сотрудничество с клиентами по согласованию контрактов

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

4. Реагирование на изменения в соответствии с планом

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

12 принципов Agile Manifesto

1. Удовлетворенность клиентов за счет непрерывной поставки продукта

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

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

Устали от использования Асаны?

Узнайте, почему Asana неэффективна для управления проектами и почему вам нужна альтернатива Asana.

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

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

3. Соблюдать установленные сроки поставки рабочего продукта

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

4. Все заинтересованные стороны должны часто сотрудничать, чтобы гарантировать, что проект идет в правильном направлении

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

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

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

6. Предпочитайте личное общение другим методам

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

7. Работающее программное обеспечение — главный критерий прогресса

Единственный фактор для измерения успеха — это поставка работающего продукта, удовлетворяющего потребителя. До Agile было много критериев успеха, и это приводило к падению качества конечного продукта.

8.Постарайтесь поддерживать постоянный темп развития

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

9. Поддерживайте качество продукта, обращая внимание на технические детали

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

10. Сохраняйте простоту

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

11. Содействовать самоорганизации в команде

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

12. Регулярно размышляйте о своей работе для постоянного улучшения

Методологии

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

Начало работы с Agile

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

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

Дополнительные ресурсы

---

---

12 Agile принципов для мотивации вашей команды и удовлетворения ваших клиентов

В Easy Agile мы придерживаемся принципов гибкой разработки (конечно) и стремимся помочь командам разработчиков программного обеспечения применять гибкие методологии на практике.Однако, делая так много каждый день, легко упустить из виду основные принципы Agile-манифеста.

Вы, наверное, думаете, что читали принципы Agile раньше, а теперь применяете их на практике … весь день, каждый день. Зачем нам к ним возвращаться?

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

Неизменная актуальность принципов Agile-манифеста

Agile-манифест фокусируется на:

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

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

Организация, позволяющая создавать работающее программное обеспечение

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

Одна цель — создать работающее программное обеспечение, которое можно постоянно обновлять. Но это легче сказать, чем сделать без помощи специализированных инструментов, таких как Jira, цель которой — помочь гибким командам управлять выбранной гибкой структурой, будь то Kanban или Scrum.(Вы можете прочитать наше руководство о различиях между Kanban и Scrum … или о том, как их использовать вместе. 💪)

Теперь давайте посмотрим, какие из 12 Agile принципов попадают в эту категорию — # 3, # 7 и # 8 — и как Jira помогает реализовать фреймворк, который их придерживается.

«Часто доставляйте работающее программное обеспечение, от пары недель до пары месяцев, с предпочтением более коротких сроков».

Atlassian (создатели Jira) прекрасно резюмирует воплощение этого принципа в своем определении спринта: «Спринт — это короткий ограниченный по времени период, когда команда Scrum работает над выполнением определенного объема работы.»

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

«Рабочее программное обеспечение — это основная мера прогресса».

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

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

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

Время для совместной работы в команде

Вы — гибкая команда, поставляющая работающее программное обеспечение и использующая такой супер-инструмент, как Jira, для планирования своей работы и отслеживания своего прогресса. Но чтобы по-настоящему следовать ценностям Agile, нужно человеческое чутье. Пожалуйста, поприветствуйте Agile-принципы №4, №6, №11, №5 и №12 на сцене.

«Деловые люди и разработчики должны ежедневно работать вместе на протяжении всего проекта».

Ежедневные встречи стоя являются проявлением этого принципа.На этой встрече каждый член команды рассмотрел три темы: (1) над чем они работали вчера; (2) над чем они работают сегодня; и (3) что мешает им добиться прогресса сегодня.

«Самый действенный и действенный метод передачи информации команде разработчиков и внутри нее — это личное общение».

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

«Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами».

Ну, во-первых, что такое самоорганизующаяся команда? Ему не нужно внешнее руководство или микроменеджмент, чтобы понять, над чем работать и как эта работа определяется и расставляется по приоритетам. Эти команды выясняют, как планировать свою работу, итерации для ее выполнения, а затем совместно работают над тем, как постоянно улучшаться.Гибкие церемонии Scrum — стоя, планирование спринта, обзор спринта и ретроспектива — являются рабочим примером этого.

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

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

«Команда регулярно размышляет о том, как стать более эффективной, а затем соответствующим образом настраивает и корректирует свое поведение».

Этот принцип прекрасно описывает ретроспективу — собрание команды, чтобы поразмышлять о вашем последнем спринте или итерации работы и обсудить, как улучшить в следующем. Ответив на эти вопросы: (1) Что прошло хорошо ?; (2) Что могло быть лучше ?; и (3) Что мы можем улучшить в следующий раз? ваша команда сотрудничает и взаимодействует, стремясь стать более эффективными.

Достижение удовлетворенности клиентов

И последнее, но не менее важное в гибких принципах — это потребности клиентов. Кто ваш покупатель? Что им нужно? Как вы реагируете на их отзывы, чтобы убедиться, что вы предоставляете работающий продукт, который им нравится? Введите принципы №1, №2, №9 и №10.

«Нашим высшим приоритетом является удовлетворение потребностей клиента за счет своевременной и непрерывной поставки ценного программного обеспечения».

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

«Приветствуем меняющиеся требования даже на поздних этапах разработки. Гибкие процессы используют изменения для конкурентного преимущества клиента».

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

«Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность».

Одно слово: ретроспектива.

Хорошо, еще два слова: обзор спринта.

В контексте принципа № 9 ретроспектива и спринт — это две agile-церемонии, которые необходимо использовать для постоянной корректировки качества и дизайна вашего программного обеспечения в соответствии с потребностями ваших клиентов.

«Простота — искусство максимального увеличения объема незавершенной работы — очень важна».

Представьте, что у вас есть просмотры профилей ваших клиентов (персонажей), визуальное отображение их пути по вашему продукту (карта пользовательских историй) и приоритетное представление вашего плана по доставке продукта (дорожная карта).Какое время быть живым! Если вы делаете все три, скорее всего, ваша команда прекрасно понимает, правильно ли вы выполняете работу. 💪

Внедрение 12 принципов гибкой разработки в действие

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

Ознакомьтесь со всеми нашими гибкими решениями на торговой площадке Atlassian!

12 принципов Agile | Товарная доска

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

Давайте посмотрим:

Принцип гибкости 1

«Нашим высшим приоритетом является удовлетворение потребностей клиентов за счет своевременной и непрерывной поставки ценного программного обеспечения.”

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

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

Принцип гибкости 2

«Приветствуем изменение требований даже на поздней стадии разработки.Гибкие процессы используют изменения для конкурентного преимущества клиента ».

Море SaaS постоянно меняется. Единственный способ удержать голову над водой — это адаптироваться.

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

Принцип гибкости 3

«Доставляйте работающее программное обеспечение часто, от пары недель до пары месяцев, с предпочтением более коротких сроков.”

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

Принцип гибкости 4

«Деловые люди и разработчики должны ежедневно работать вместе на протяжении всего проекта».

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

Частое общение между межфункциональными командами обеспечивает доверие, прозрачность и, как следствие, лучшие и более актуальные продукты.

Принцип гибкости 5

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

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

Если у вас есть подходящая команда, все, что вам нужно сделать, это предоставить им подходящую рабочую среду и любую поддержку или ресурсы, в которых они нуждаются. Это устраняет необходимость в ручном управлении и микроменеджменте.

Принцип гибкости 6

«Самый действенный и действенный метод передачи информации команде разработчиков и внутри нее — это личное общение.”

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

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

Принцип гибкости 7

«Работающее программное обеспечение — главный критерий прогресса».

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

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

Принцип гибкости 8

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

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

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

Принцип гибкости 9

«Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность».

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

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

Принцип гибкости 10

«Простота — искусство максимального увеличения объема незавершенной работы — имеет важное значение».

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

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

Принцип гибкости 11

«Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами».

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

Принцип гибкости 12

«Команда регулярно размышляет о том, как стать более эффективной, а затем соответствующим образом настраивает и корректирует свое поведение».

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

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

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

. . .

productboard — это система управления продуктами, которая позволяет командам быстрее выводить нужные продукты на рынок. Доска продуктов, построенная на основе структуры Product Excellence, служит специальной системой записи для менеджеров по продукту и помогает каждому выбрать нужные функции, которые нужно создавать дальше. Получите доступ к бесплатной пробной версии productboard уже сегодня.

Четыре ценности и 12 принципов Agile-манифеста

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

1. Люди и взаимодействия важнее процессов и инструментов
Первое значение в Agile Manifesto — «Индивидуумы и взаимодействия важнее процессов и инструментов.«Ценить людей выше, чем процессы или инструменты, легко понять, потому что именно люди отвечают на потребности бизнеса и управляют процессом разработки. Если процесс или инструменты стимулируют разработку, команда менее восприимчива к изменениям и с меньшей вероятностью будет удовлетворять потребности клиентов. Коммуникация — это пример разницы между оценкой людей и процессом. В случае с отдельными людьми общение происходит плавно и происходит при возникновении необходимости. В случае процесса коммуникация запланирована и требует определенного содержания.

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

3. Сотрудничество с клиентом вместо переговоров по контракту
Переговоры — это период, когда заказчик и менеджер по продукту прорабатывают детали поставки, с моментами, когда детали могут быть пересмотрены. Сотрудничество — это совершенно другое существо.С такими моделями разработки, как Waterfall, заказчики обсуждают требования к продукту, часто очень подробно, до начала любой работы. Это означало, что заказчик был вовлечен в процесс разработки до начала разработки и после ее завершения, но не во время процесса. Agile Manifesto описывает клиента, который участвует и сотрудничает на протяжении всего процесса разработки, создавая. Это значительно упрощает разработку, чтобы удовлетворить их потребности клиентов. Гибкие методы могут включать клиента через определенные промежутки времени для периодических демонстраций, но проект может так же легко иметь конечного пользователя, как ежедневную часть команды и посещать все встречи, гарантируя, что продукт соответствует бизнес-потребностям клиента.

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

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

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