Принципы agile что это
Все, что вы хотели знать про Agile: принципы, методология, инструменты и отличие от Scrum
Agile-коуч ScrumTrek, эксперт в области Scrum и традиционного проектного управления
В следующем году термину Agile и его основополагающему документу исполнится 20 лет. В Россию Agile-практики добрались сильно позже, и сейчас мы наблюдаем стремительный рост их применения.
Я бы даже сказал, что Agile в России добирается до «позднего большинства» на кривой продукта — ведь в большинстве инновационных компаний гибкие подходы уже нашли себе место.
Но даже несмотря на то, что по теме в России издано достаточно литературы, для многих людей вокруг 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 дает высокий прирост эффективности. Исследования компании StandishGroup показывают, что гибкие проекты в среднем более успешные, чем ватерфольные.
В некоторых случаях 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: определение и краткая история
Как бы непривычно это ни звучало, но серьезно разрабатывать программное обеспечение и управлять проектами начали уже в 70-х годах прошлого века. Именно в 1970 году американский ученый-компьютерщик Уинстон Ройс составил документ, называвшийся «Управление развитием крупных программных систем». В нем он приводил критику последовательной разработки, указывая на то, что разработка программного обеспечения не должна походить на работу сборочной линии (как, например, делается в автомобильном производстве), где новые детали по очереди добавляются в последовательные фазы.
Вместо того чтобы ждать, пока будут поочередно завершены все этапы (фазы), Ройс предложил применять фазовый подход. Суть его в том, что изначально собираются все требования, необходимые для проекта, после чего завершается вся архитектура, создается дизайн, записывается код и т.д.
На основе этого в 90-х удалось создать комплекс гибких методов разработки ПО, способных заменить сложные и трудоемкие методы. Происходило это так:
Все вместе эти методы объединились под общим названием гибких методов разработки ПО.
Четыре года спустя – в 2001 году в штате Юта (США) на курорте Snowbird собрались семнадцать разработчиков программного обеспечения. В результате обсуждения методов разработки был опубликован «Манифест о гибкой разработке программного обеспечения Agile» (в переводе с английского понятие «agile» означает «подвижный», «проворный» или «быстрый», но в большинстве случаев его переводят именно как «гибкий»). Он и задал темп всей дальнейшей работе над созданием ПО.
Манифест Agile
Манифест, созданный программистами, включает в себя 4 базовых идеи и 12 принципов эффективного управления проектами. Любая из систем управления проектами на основе Эджайл (о системах мы поговорим позже) опирается именно на эти идеи и принципы, хотя и использует их в разных вариациях.
Постигая Agile, в дополнение к обзору идей и правил обязательно ознакомьтесь с этим небольшим видео, где специалист по проектному управлению, консультант и бизнес-тренер Алексей Таченков рассказывает об основах системы.
Чтобы реально осуществить на практике вышеизложенные идеи и принципы, необходимо придерживаться нескольких правил. Только тогда Agile-менеджмент проекта может быть эффективен.
Ключевые моменты в применении Agile
Agile-методология основывается, в первую очередь, на визуальном контроле. Чаще всего участники проекта, работая над достижением результата, пользуются специальными цветными карточками. Один цвет сигнализирует о завершении планирования какого-то элемента конечного продукта, другой – о завершении его разработки, третий – о готовности и т.п. Визуальный контроль позволяет команде иметь наглядное представление о текущем состоянии процесса и гарантирует одинаковое видение проекта всеми ее членами.
Члены команды и клиент в большинстве случаев работают вместе и рядом. Благодаря этому существенно ускоряются многие рабочие процессы, которые связаны с информированием участников проекта. Кроме того, совместная работа способствует созданию здоровой атмосферы для плодотворного и эффективного сотрудничества и скорейшего достижения результатов.
Когда руководитель проекта, команда и клиент действуют сообща, исключается опасность недопонимания целей и утери информации. Все рабочие процессы становятся максимально прозрачными, а это значит, что любые возникающие проблемы можно разрешать практически моментально и находить лучшие варианты их решения.
Особое внимание нужно уделить руководителю проекта. Его нельзя назвать человеком, раздающим указания налево и направо. Руководитель здесь выступает скорее в роли лидера, который задает направление и определяет правила сотрудничества и работы. Другими словами, Agile-управление является адаптируемым.
Еще одним важным моментом Agile-методологии является разделение всего объема проекта на несколько более мелких составных частей. Такой подход многократно упрощает процесс разработки, а отдельные группы команды могут фокусироваться каждая на своей конкретной задаче.
Работая над одним циклом, участники проекта овладевают новыми навыками и получают новые знания, а также анализируют допущенные в процессе ошибки. Все это сводит вероятность совершения подобных ошибок в будущем (в следующих циклах и других проектах) практически к нулю.
И, наконец, последний значимый элемент подхода – это спринты и ежедневные встречи. Спринтами называются ограниченные конкретными сроками (дедлайнами) отрезки времени, в течение которых команда успевает выполнить определенные задачи. Именно благодаря спринтам команда может видеть результаты своих действий.
Если же мы разделим все время, отведенное на проект, на несколько спринтов, получим конкретное их количество; пусть их будет 15. Каждый спринт длится, к примеру, две недели. Вот как раз в течение этих двух недель (времени, отведенного на спринт) участники каждый день встречаются для обсуждения процесса и прогресса.
Ежедневные встречи не должны превышать 15 минут. Организуются они для того, чтобы каждый член команды дал себе же ответ на три вопроса:
Ответы на эти вопросы позволяют держать под контролем процесс, понимать, на какой стадии находится каждый из участников команды, и устранять потенциальные проблемы на пути к цели. Если же обобщить, то внедрение Agile-методологии возможно, если соблюдается несколько условий:
В настоящее время проект-менеджмент с поддержкой Аджайл по большей части распространен в IT-сфере, однако и деловая сфера его начинает осваивать. Эта система применяется в обучении, маркетинге, бизнесе. Гибкое управление проектами берется на вооружение множеством компаний и государственных структур.
Примеры: правительство Новой Зеландии, правительство Нигерии, Норвежский пенсионный фонд, компания Return Path (программное обеспечение), компания Oreo (производство печенья), компания Aviasales (крупнейший поисковик авиабилетов), компания Hewlett-Packard (крупнейшая американская IT-компания), «Сбербанк» (наверное, знаете, что это).
Эти и многие другие организации используют в работе самые разные методы управления проектами, основанные на Agile. И поговорить об этих методах не менее важно, чем о самой методологии.
Популярные методы управления проектами
Существует немало методов проект-менеджмента, которые применяются разными современными компаниями. Но самыми известными и востребованными среди них по праву считаются Scrum (Скрам) и Kanban (Канбан).
Метод Scrum
Среди всех методов системы Agile Scrum отличается тем, что делает основной упор на качественный контроль рабочего процесса. Впервые описавшие его японские специалисты по стратегическому менеджменту Хиротака Такуэти и профессор в области научно-технических знаний Икуджиро Нонака называют метод «подходом в рэгби», где Scrum является «борьбой за мяч».
Метод заключается в том, что разработка проекта разделяется на спринты, по окончании которых клиент получает улучшенное ПО. Спринты строго фиксируются по времени, и могут длиться от 2 до 4 недель. Рабочий процесс в одном спринте включает в себя несколько стадий:
В большинстве случаев Скрам применяется в работе со сложным ПО и для разработки продукта с использованием инкрементных и итеративных методов. Благодаря ему серьезно повышается производительность команды и сокращаются временные затраты на достижение цели.
Scrum улучшает результаты, помогает адаптировать проект к изменениям, обеспечивает более точную оценку при меньших трудозатратах на анализ и позволяет эффективнее контролировать этапы работы и сценарий проекта. Все это как нельзя лучше соответствует бизнес-целям.
Метод Kanban
Канбан – еще один метод, делающий командную работу более результативной и продуктивной. Смысл его сводится к приданию процессу разработки максимальной прозрачности и равномерному распределению нагрузки среди участников проекта. Важная особенность Kanban еще и в том, что он мотивирует людей на постоянное сотрудничество, совершенствование и обучение.
Работа по методу Kanban выстраивается на нескольких принципах. Во-первых, вся информация о проекте должна быть визуализирована, что позволяет видеть накладки, ошибки и недочеты и активно их устранять. Во-вторых, работа над одной задачей должна вестись одновременно всей командой – это помогает сбалансировать усилия и получаемые результаты, исключает неравномерное распределение нагрузки. И, в-третьих, время на выполнение всех задач строго контролируется, благодаря чему оптимизируется процесс и экономится время.
В отличие от Скрам, Канбан обрел популярность намного позже, но это ни в коей мере не умаляет его достоинств и не делает менее эффективным. Метод полезен как в IT-области, так и в бизнес-сфере.
Это лишь примеры основных методов управления проектами, основанных на Agile. Но не стоит пренебрегать и другими методами, такими как PRINCE2, Lean, Six Sigma, XP, CCPM, ECM, Waterfall и другие. К тому же у Аджайл, наряду с преимуществами, есть и некоторые недостатки.
Плюсы и минусы Agile
Постигая Agile, важно знать как о положительных, так и об отрицательных сторонах этой методологии. Начнем с плюсов.
В первую очередь стоит отметить, что Agile-управление очень гибкое. Если, например, традиционная методология указывает на конкретные этапы работы, то Эджайл легко подстраивается под потребителя конечного продукта и требования заказчика.
Собственно, и в конечном продукте число дефектов минимизируется, ведь он является результатом тщательной проверки качества, которая проводится по завершении каждого этапа-спринта.
Кроме того, Agile быстро запускается, легко реагирует на изменения, позволяет команде разработчиков и клиентов поддерживать постоянную связь в реальном времени. Преимущества очевидны, но давайте поговорим и о минусах.
Недостатки методологии состоят в том, что, во-первых, постоянная обратная связь может приводить к тому, что все время будет переноситься и дедлайн проекта, тем самым создавая угрозу бесконечно продолжающейся работы. Если заказчик видит, например, только результаты, но не имеет представления об усилиях, потребовавшихся для их достижения, он будет все время требовать улучшений.
Второй недостаток заключается в необходимости адаптировать под изменяющиеся условия проекта проектную документацию. При отсутствии надлежащего информирования команды об изменениях или дополнительных функциях документы с функциональными требованиями или архитектурой могут оказаться неактуальными на текущий момент времени.
Третьим существенным минусом Аджайл можно назвать необходимость в частых встречах. Они, конечно, способствуют повышению эффективности работы, но все же постоянное отвлечение членов команды может сказаться на процессе отрицательно, ведь внимание людей систематически уходит в сторону от решаемых задач.
Сюда же можно отнести такие вещи как необходимость в постоянном присутствии клиента, невозможность выстраивать долгосрочные планы и потребность в мотивированных и высококвалифицированных специалистах. Кстати, последнее в огромной степени касается и внедрения Agile-управления в деятельность организации. И, постигая Agile, с темой ее внедрения тоже нужно познакомиться.
Внедрение Agile
Примеров внедрения Эджайл в работу компаний есть достаточно много. И практически все они говорят, что оно требует целого комплекса важных мероприятий.
Для начала выбирается конкретный метод, что зависит от условий проекта. Затем определяются задачи и цели, основной дедлайн и сроки спринтов, численность команды и другие составляющие работы над проектом. Важно подобрать метод, отвечающий максимальному количеству требований.
Как мы и сказали, для внедрения Agile необходима команда профессионалов. Все ее члены должны знать базовые идеи и принципы методологии и уметь их применять. Если в компании нет таких людей, сотрудников нужно обучить. Руководство компании, решившей перейти к использованию Аджайл, также должно четко понимать, готова ли организация к изменениям, можно ли применять систему к своим проектам и т.д. Чаще всего, чтобы ответить на эти вопросы, приходится обращаться к специалистам по Agile.
На следующем этапе приглашается человек, имеющий опыт работы с системой. Он демонстрирует ее, разъясняет суть спринтов и действий, функции членов будущей команды, особенности взаимодействия между ними и другие вопросы. И только после этого формируется новая команда, распределяются роли, задачи и обязанности, подбираются инструменты для ведения аналитики, отчетности и т.д.
Окончательным этапом будет первый опыт с Аджайл, т.е. первый проект с его использованием. Нужно понимать, что неизбежны ошибки, недочеты, нестыковки, отставания. Придется отказаться от одних инструментов и заменять их другими, возможно – менять роли между людьми в команде. Первый опыт – это процесс адаптации, причем адаптации двухсторонней: компания привыкает к методологии, а методология подстраивается под компанию.
Заключение
Подытоживая данный обзор, напомним, что теория и практика – это две разные вещи. Новые методики и технологии и их внедрение – это своеобразный вызов команде, и как прийти к большей эффективности – дело всегда индивидуальное. Agile – это не панацея и не гарантия успеха, но он позволяет установить правильный курс и найти ориентиры на пути.
Для реализации любого проекта обязательно придется что-то менять, искать новые решения, генерировать необычные идеи. Лишь подстраиваясь под постоянно меняющиеся условия работы и требования заказчиков, можно найти верные способы действий. И гибкая методология управления проектами Agile может стать в этом деле верным помощником.