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

Что такое 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

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

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

Давайте начнем с того, что такое «Agile»

Этот термин появился в начале 2000-х годов в IT-индустрии, когда в штате Юта был издан «Манифест гибкой разработки программного обеспечения». Манифест был разработан группой программистов-энтузиастов, которые хотели понять, что именно лежит в основе разработки востребованного и полезного IT-продукта. Он включает в себя четыре основных идеи и двенадцать принципов эффективного управления проектами, речь о которых пойдет ниже. Также следует добавить, что в настоящее время существует множество Agile-подходов: Kanban, SCRUM, Extreme programming, Lean и другие, но всех их объединяет соответствие 4-м базовым идеям, описанным в том самом Agile-манифесте.

Идеи Agile:

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

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

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

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

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

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

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

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

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

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

12 основополагающих принципов Agile манифеста:

1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и своевременной поставке ценного программного обеспечения.
    
2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
    
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
    
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
    
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
    
6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
    
7. Работающий продукт — основной показатель прогресса.
    
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
    
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
    
10. Простота — искусство минимизации лишней работы — крайне необходима.
     
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
     
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

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

Одной из распространенных Agile методологией является — Scrum, в котором, как раз и существуют вышеупомянутые Agile Roles. 

Scrum – это методология (фреймворк) управления проектами с определенным и обязательным к выполнению сводом правил.

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

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

Scrum Rituals — это утвержденные процессы, которые команда выполняет на регулярной основе на протяжении всего проекта. К scrum-ритуалам относятся: планирование спринта, ежедневная синхронизация, спринт ревью и ретроспективы. Каждый из этих ритуалов выполняется в строгом соответствии и всей командой.    

 

Основные роли внутри Agile Scrum-команды:

Product Owner (PO) — является владельцем продукта. Он формирует и описывает требования продукта и его функционал, приоритезирует задачи команды на спринт и помогает команде планировать. Также он несет ответственность за ценность продукта для пользователей и принимает работу команды на ревью, но не несет ответственности за сроки запуска продукта или сдачи функционала. В роли Product Owner также может выступать Product Manager. 

Product Manager (PM) — может выполнять роль Product Owner-a. Этот человек занимается исследованием рынка, доносит желание клиента, отвечает за стоимость продукта, отвечает за все коммуникации с рынком, которые ваш продукт будет выполнять. Вопросы качества и деливери (поставки продукта) не входят в его компетенцию. Может выполнять роли Product Owner и Scrum Master, но никогда обе сразу. 

Scrum Master (SM) — несет ответственность за сроки сдачи спланированных принтов. В этой роли также может выступать Project Manager, так как основные задача скрам-мастера это: оптимизация и улучшение рабочих процессов, создание комфортных условий работы команды, выявление проблем и нахождение путей для их решения, что функционально перекликается с ролью Project Manager.

Project Manager (PM) — отвечает и за качество, и за деливери продукта, поэтому его роль может совмещаться с ролью скрам-мастера. Это человек, который следит и супевайзит проект, отвечает за процессы коммуникации на проекте. Следит за тем, как чувствует себя команда и как информация циркулирует по организации. Помогает команде убирать препятствия на пути к успеху. 

Scrum Team (ST) — включает в себя всех кросс-функциональных членов команды для достижения поставленных целей продукта. Команда не решает какие требования являются приоритетными для продукта, это задача роли Product Owner, но определяет какой набор задач возьмет в спринт. Команда должна быть взаимозаменяемой с фиксированным составом, чтобы чувствовать себя одним целым. 

 

Полезная литература: 

Дж. Сазерленд «Scrum. Революционный метод управления проектами»

Д. Андерсон «Канбан. Альтернативный путь в Agile»

K. Schwaber, J. Sutherland “The Scrum Guide”

Ирина Вишнетская, бизнес проджект менеджер в PlayTech
Автор статьи

При цитировании материалов раздела «Блог» на www.eduget.com активная ссылка на сам материал или на страницу www.eduget.com – обязательна. Любое использование материалов раздела «Статьи» на www.eduget.com (материала целиком) возможно исключительно по предварительному письменному разрешению правообладателя. Благодарим за сотрудничество!

Что такое Agile: методология или философия? :: РБК Pro

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

Фото: Andreas Rentz / Getty Images

Agile — философия, Scrum — ее реализация

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

Agile манифистирует:

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

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

Четыре ценности Agile: «X важнее Y»

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

Что такое Agile. Гайд по гибким методологиям, или Как работать с пользой.  Часть 1

Алена Лепилина

Agile — гибкий подход к разработке, включающий разные методологии (Scrum, Канбан, ХР, Lean и другие). Об этом знают многие. Но есть десятки мелочей и всяких интересных штук, которые не лежат на поверхности.

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

Большой взрыв проектов

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

Обычно процессы работают в рамках каскадной модели (или waterfall model) — все происходит поэтапно и последовательно. Проще говоря, «вижу цель — иду к цели». И если в какой-то момент требования к продукту, конечной цели меняются, иногда приходится переделывать заново. Как только превосходно отточенный план сталкивается с реальностью, он сразу рассыпается в прах. Но вместо того чтобы выбросить в мусорную корзину и сам план, и свой подход к нему, руководители делают вид, будто план работает, и даже нанимают для этого специалистов. По сути, они платят людям за то, что те им лгут.

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

Agile-методы же призваны бороться с этим за счет своей гибкости. Можно сказать, что Agile — сборная солянка нескольких подходов, призванная минимизировать всяческие риски при помощи набора принципов. Эти самые принципы и 4 основных идеи собраны в Agile-манифесте, датированном 2001 годом.

Манифест Agile

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

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

Как устроены процессы

Посмотрим, как можно работать по эджайлу. Для примера возьмем Scrum — сегодня это самая популярная гибкая методика. Джефф Сазерленд, автор книги «Scrum», изобрел эту методику, чтобы справиться с недостатками классического управления проектами.

1. Выберите владельца продукта — это человек, который видит, к какой цели вы идете и что хотите получить в итоге.

2. Определитесь с командой — от 3 до 10 человек, владеющих навыками, которые позволят получить результат (т. е. работоспособный продукт).

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

4. Составьте бэклог продукта — соберите в одном месте (желательно на Agile-доске) все-все-все требования к продукту и расставьте приоритеты. Владелец продукта должен продумать и собрать все пожелания. Затем команда должна оценить бэклог, чтобы понять, возможно ли все это сделать и сколько времени потребуется.

Так выглядит agile-доска в Яндексе, — источник.

5. Запланируйте спринты — отрезки времени (неделя или две), за которые команда выполняет определенный набор задач. Спринты будут регулярными: например, 15 раз по две недели, пока получится готовый продукт.

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

7. Делайте обзоры — по итогам спринта команда рассказывает, что удалось сделать, и демонстрирует работоспособные части продукта. На обзоры может прийти кто угодно: владелец продукта, главный заказчик или даже потенциальные клиенты.

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

Более подробно о том, как внедрить скрам и повысить эффективность команды, читайте в этой статье.

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

Знать Agile в лицо

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

1. Минимизация рисков — это главная цель в рамках любого гибкого подхода.
2. Итеративная разработка — работа в коротких циклах.
3. Люди и коммуникация — самое важное.

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

• Заказчику нужно вовремя получать хотя бы минимально работоспособный продукт (не важно, речь идет о ПО или же о других процессах и явлениях), менять условия, при этом не оставаясь с дыркой от бублика в кармане, — это уже к вопросу о страховании рисков.

• Команде на руку общение с заказчиком и коллегами (чтоб без этого: «Вы меня неправильно поняли — переделайте все быстренько. И да, это надо вчера!»), прозрачность процессов, что уменьшает шансы на неожиданности, быстрое решение проблем. Ну и многие понимают, куда девается время и где работа стопорится. Мелочь (на самом деле нет), а приятно.

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

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

Кому это может не понравиться?

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

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

Читайте продолжение:

Что такое Agile. Гайд по гибким методологиям, или Как работать с пользой. Часть 2
Что такое Agile. Гайд по гибким методологиям, или Как работать с пользой. Часть 3

P.S.  Хотите каждую неделю получать полезные советы из самых интересных книг по бизнесу и маркетингу, узнавать о новинках и получать скидки? Подписывайтесь на нашу рассылку.  В первом письме — подарок.

Что такое Agile и Scrum

Бывает, обсуждаете что-то в компании и тут речь заходит, скажем, о новой сделке Apple. Признаться, что вы не в теме, стыдно, поэтому остается только кивать с умным видом. Знакомо?

Чтобы таких неловких ситуаций было меньше, мы запустили рубрику «На пальцах». В ней мы просим специалистов объяснить сложные вещи простыми словами.

В новом выпуске Scrum-мастер MacPaw Катя Углицких рассказывает, что такое Agile и Scrum.

Катя Углицких

Что такое Agile

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

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

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

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

Если Agile — это набор принципов, и он достаточно абстрактный, то Scrum, Kanban, TDD, BDD, Extreme programming, Pair programming — это конкретные практики с четкими правилами и ролями. Все они строятся на основе принципов Agile, но отличаются между собой. Например, в Scrum итерации называют «спринтами», а в Kanban понятия «итерация» вообще нет.

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

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

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

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

Как IT-компании работали до того, как Agile стал популярным

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

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

Только представьте, вы целых 2-3-5 лет работаете над продуктом, прикручиваете ему функциональность, которая должна стать killer feature (особенная характеристика, которой нет у продуктов конкурентов — ред.) и наконец решаетесь показать его миру. А потом оказывается, что продукт очень нишевый — он занимает лишь десятую или сотую часть всего рынка.

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

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

Когда Agile стал популярен

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

В 2001 году авторы экстремального программирования, DSDM, Scrum и других методик управления проектами (всего из было 17 человек) собрались вместе, чтобы объединить свои наработки в одну методологию. Вместе они подписали единый Agile-манифест.

Спустя 18 лет Agile-практики используют 97% IT-компаний. В украинские IT-компании Agile пришел около 10 лет назад.

Что такое Scrum

Scrum — одна из практик, основанных на идеях Agile. Чаще всего команды выбирают именно ее.

Scrum похож на децентрализацию власти: если классический проджект-менеджер отвечает и за людей, и за бюджет, и за продукт, то в Scrum за эти элементы отвечают три разных человека.

Командам, которые только начинают работать по принципам Agile, стоит выбрать именно Scrum.

Scrum-команда

В Scrum-команде есть три роли:

Член Scrum-команды — сюда входят все участники команды разработки.

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

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

Product Owner — это человек, который управляет концепцией проекта и приоритетом выполнения задач.

Бывает, что Product Owner и Scrum-мастер — один и тот же человек, но это неправильно. Задача Scrum-мастера — бросать вызовы не только команде, но и Product Owner.

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

Scrum-встречи

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

Daily Scrum — ежедневная встреча, на которой выступает каждый член команды. Это помогает всем синхронизироваться. На Daily Scrum команда отвечает на три основных вопроса:

• Что я сделал вчера?
• Что я буду делать сегодня?
• Что мне мешает? Нужна ли мне чья-то помощь?

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

Reviews — это презентация в конце каждой итерации, на которой команда показывает демо-версию продукта. На эти мероприятия приходят потребители, которые просили команду сделать эту функцию, Product Owner и владельцы компании.

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

Выводы из практики применения Scrum

1. Раньше в нашей компании отдел маркетинга работал отдельно, разработчики — отдельно. Каждый был в своем мире.
2. Раньше у нас были компонентные команды: разработка, маркетинг, веб-разработка. Когда мы работали над одним продуктом, то все занимались исключительно им. Это было наше бутылочное горлышко. Сейчас мы работаем над несколькими продуктами одновременно. Над каждым из них трудятся по несколько кросс-функциональных команд, которые мы создаем под определенные потребности.
3. Из-за того, что наша команда самоорганизованная, никто не хочет брать на себя ответственность. Когда команды большие, им сложнее самоорганизовываться, вовлеченность может падать. Поэтому в Scrum-команде должно быть не более 9 человек. Вовлечение каждого влияет на то, насколько ясна цель команды.
4. Из-за того, что мы хотим услышать каждого, иногда тратим много времени на принятие решения.

Кому кроме продуктовых IT-компаний подходят практики Agile

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

Кроме IT-отрасли за последние 5-7 лет Agile начали применять многие украинские банки, фармацевтические компании и неприбыльные организации. К примеру, его используют программисты ProZorro и «ПриватБанка».

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

Читайте нас в Telegram

Читайте также:

Материалы по теме IT:

Что такое Agile простыми словами

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

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

Оглавление

1. Что такое методика Agile?
2. Краткая история возникновения Agile
3. Базовые принципы методики Agile
4. Суть итеративно-инкрементального подхода
5. Примеры применения Agile на практике
6. Какие инструменты есть у Agile?
7. Преимущества и недостатки Agile
8. Специфика внедрения Agile
9. Заключение

Что такое методика Agile?

Если перевести название методики на русский язык, то окажется, что это прилагательное. Дословный перевод – «шустрый» или «маневренный». Отсюда и смысл методики. Она предполагает оперативную смену своего движения без потери скорости или эффективности. На основе этого манифеста, который был разработан трудами различных практиков в течение многих лет, появились другие известные подходы. Это тот же Scrum, Feature Driven Development, eXtreme Programming. Все перечисленные подходы были сформулированы авторами манифеста Agile.

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

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

Краткая история возникновения Agile

Первые попытки придумать оптимальную систему управления проектами появились с первыми серьезными разработками ПО. Это 70-е годы прошлого века. Автором первого подобного документа под названием «Управление развитием крупных программных систем» является американский ученый Уинстон Ройс. Суть документа в том, что разработка ПО не может иметь строго регулируемые правила, как это есть на том же автомобильном производстве.

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

В 90-х годах, на основе указанного документа, стали активно появляться различные гибкие методы разработки ПО. Это метод разработки приложений RAD, платформа Scrum, методология Crystal Clear. Все эти методы разработки ПО стали называться гибкими. В 2001 году группа разработчиков по итогу обсуждения вывела и опубликовала «Манифест о гибкой разработке программного обеспечения Agile».

Базовые принципы методики Agile

Установленные идеи методологии Agile стали отправной точкой для разработки основных принципов этой системы. Всего есть 12 базовых принципов:

1. Принципы говорят о том, что нужно поставлять своим клиентам ПО регулярно, вовремя и через одинаковые временные промежутки;
2. Делать поставки программного продукта нужно как можно чаще;
3. Требования к конечному продукту должны постоянно меняться и адаптироваться, в зависимости от выявленных обстоятельств;
4. Нужна поддержка сотрудничества между заказчиком и разработчиками на время всего цикла разработки продукта;
5. Также нужно держать связь и со всеми разработчиками, которые трудятся в команде;
6. Прямой контакт с разработчиками и их дополнительное мотивирование должно быть в приоритете.
7. Скорость работы команды разработчиков должна быть такой, чтобы при ней поддерживался непрерывный темп;
8. Мерилом прогресса работы компании может быть только качество рабочего ПО;
9. Рабочий процесс не должен быть перегружен сторонними процессами – он обязан быть максимально простым. Таким же простым и понятным должен быть готовый программный продукт;
10. У членов команды должна быть возможность самим принимать решения, если, по их мнению, это поспособствует прогрессу в работе. Это может быть обмен идеями, организация в подгруппы, общение с другими участниками проекта и прочее;
11. На дизайнерские и технические детали программного продукта нужно уделять особое внимание;
12. Важно постоянно подстраиваться под внешние факторы и меняющуюся среду.

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

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

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

Суть итеративно-инкрементального подхода

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

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

Основные отличия Agile от Scrum

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

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

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

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

Примеры применения Agile на практике

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

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

Какие инструменты есть у Agile?

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

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

Преимущества и недостатки Agile

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

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

Специфика внедрения Agile

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

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

Понять, готова ли команда к Agile, можно по следующим признакам:

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

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

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

Заключение

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

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

Хотите получать статьи и новости в удобном формате? Подписывайтесь на наш Телеграм-канал.

Что такое Agile? | Atlassian

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

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

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

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

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

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

Интеграция Agile & Scrum разработки и методологии

Управление проектом гибридной модели

Шаян Алам, ПМП

Методологии разработки

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

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

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

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

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

5 советов по интеграции групп разработки agile и scrum с группами разработки водопада

Попытка внедрить Agile как итеративный водопад не сработает

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

Разработка / контроль качества могут быть итеративными, в то время как проект и интеграция заказаны

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

Остерегайтесь ползучести прицела

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

Играйте спокойно с QA

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

Будьте внимательны к конечному пользователю

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

Если вам нужна дополнительная информация по этой теме, отправьте электронное письмо на адрес [адрес электронной почты защищен]. Мы приветствуем ваши вопросы, комментарии и отзывы.

Другие часто просматриваемые статьи

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

Agile, Waterfall и неопределенность в управлении проектами: Agile Development vs. Waterfall

Введение в Scrum: преимущества и методы гибкой разработки программного обеспечения с помощью Scrum.

Scrum как управление проектами: сравнение и контрастирование Agile Development Scrum с традиционными методологиями управления проектами.

Agile Development & Scrum соответствует PMP: Agile Development, ее сравнение и отличие от методологии PMI.

ежедневных схваток в распределенном мире: формальное сотрудничество для сокращения накладных расходов.

Интеграция Waterfall и Agile Development: советы по интеграции методологий Waterfall и Agile Development.

3 различия между Scrum и Kanban, которые необходимо знать

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

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

Вкратце, что такое Scrum?

Не вдаваясь в подробности, Scrum — это инструмент, используемый для организации работы в небольшие управляемые части, которые могут быть выполнены кросс-функциональной командой в течение установленного периода времени (так называемый спринт, обычно продолжающийся 2-4 недели).

Для планирования, организации, администрирования и оптимизации этого процесса Scrum полагается как минимум на три предписанные роли: владелец продукта (отвечает за первоначальное планирование, расстановку приоритетов и общение с остальной частью компании), Scrum Master (отвечает за надзор). процесс во время каждого спринта), а также члены команды (ответственные за выполнение цели каждого спринта, например, за создание программного кода.)

Еще один распространенный инструмент, используемый Scrum-командами, — это Scrum Board — визуальное представление рабочего процесса, разбитого на управляемые блоки, называемые «историями», причем каждая история перемещается по доске из «backlog» (списка дел). , в незавершенное производство (WIP) и на завершение.

Вкратце, что такое Канбан?

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

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

Как скрам и канбан — одно и то же?

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

Чем отличаются Scrum и Kanban?

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

Планирование, итерация и частота кадров

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

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

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

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

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

Роли и обязанности

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

Сама команда scrum также должна быть кросс-функциональной, то есть одна команда должна иметь все ресурсы, необходимые для выполнения всей работы спринта.

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

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

Сама плата

Хотя Scrum Board и Kanban Board очень похожи, это разные животные.

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

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

Что лучше для ваших нужд?

На самом деле нет возможности ответить на этот вопрос в этой статье.

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

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

Информацию о вариантах обучения Kanban и Scrum см. Ниже, где представлены курсы, предлагаемые Cprime Learning.
Kanban Workshop
Certified ScrumMaster Workshop (CSM)
Certified Scrum Product Owner (CSPO) Workshop
Advanced Certified ScrumMaster (A-CSM)

(Сертифицированный мастер ScrumMaster)
Мастерская сертифицированного ScrumMaster (CSPO)
Advanced Certified ScrumMaster (A-CSM)

Другие ресурсы, которые могут вас заинтересовать, включают:

Статья: Подходит ли мой проект для Kanban или Scrum?

FAQ: что такое Agile, что такое Scrum

Веб-семинар: что можно делать с Канбан

Узнайте больше о Scrum и Kanban: Посетите нашу полную библиотеку ресурсов

Получите полный обзор Agile и Scrum

Погрузитесь и узнайте больше

Кэссиди Найт, писатель по Agile-техническим вопросам

Что такое Agile?

До недавнего времени Agile рассматривался как набор методов управления, относящихся к разработке программного обеспечения.Это связано с тем, что первыми сторонниками Agile были разработчики программного обеспечения, и его основополагающим документом стал Манифест по разработке программного обеспечения 2001 года. Спустя пятнадцать лет, в 2016 году, после признания Harvard Business Review, McKinsey & Company и проекта Learning Consortium Project 2015 года Agile теперь быстро распространяется на все части и все типы организаций.

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

Цели, принципы и методы гибкой разработки будут освещены на заседании форума Друкера с Гэри Хэмелом в качестве участника дискуссии.

Эволюция гибкости

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

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

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

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

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

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

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

Общее руководство принимает Agile

Поскольку программное обеспечение само по себе становится критически важным фактором практически во всех сферах бизнеса, Agile теперь распространяется на все виды организаций и во все аспекты работы, что было признано в 2016 году цитаделью общего менеджмента — Harvard Business Review — в статье «Охват гибкости» »Даррелла К. Ригби, Джеффа Сазерленда и Хираката Такеучи.

«Теперь гибкие методологии, которые включают новые ценности, принципы, практики и преимущества и являются радикальной альтернативой командно-административному управлению, распространяются в широком диапазоне отраслей и функций и даже в топ-менеджеры.Национальное общественное радио использует гибкие методы для создания новых программ. John Deere использует их для разработки новых машин, а Saab — для производства новых истребителей. Intronis, лидер в сфере облачных сервисов резервного копирования, использует их в маркетинге. C.H. Робинсон, глобальный сторонний поставщик логистических услуг, применяет их в человеческих ресурсах. Винодельня Mission Bell использует их для всего, от производства вина до складирования и управления своей группой высшего руководства ».

Центральная роль Agile для общего управления была также признана в апреле 2016 года компанией McKinsey & Company на глобальном хакатоне Agility Hackathon, в котором приняли участие около 1500 онлайн-участников:

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

Обучающий консорциум и Agile

Появление Agile для общего управления было также подтверждено выводами проекта Learning Consortium Project 2015 года. Это была группа организаций, включая Microsoft, Ericsson, CH Robinson, Magna International, Riot Games и Scrum Alliance, которые решили посмотреть, что на самом деле происходит в компаниях, которые заявляют, что практикуют гибкое управление и связанные с ним методы управления, такие как бережливое производство.На фоне противоречивых заявлений о том, является ли Agile чем-то реальным или просто управленческой прихотью, это все разговоры, проект консорциума обучения стремился выяснить, что на самом деле происходит на местах.

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

Менталитет и людей в отношении инструментов и процессов

Об Agile написано очень много. Большая часть этих работ посвящена вещам, — инструментам, процессам, методологиям, технологиям, платформам, большим данным и тому подобному.

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

Другая концепция организации

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

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

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

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

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

Консорциум SD Learning

Являясь преемником проекта Learning Consortium Project 2015 года, SD Learning Consortium (SDLC) является некоммерческой организацией, членами которой являются организации, приверженные совместному открытию самых передовых мировых целей, принципов и практик, включая, но не ограничиваясь Agile, и распространять их по всему миру, чтобы помочь преобразовать мир труда.

SDLC посещает своих членов, синтезирует то, что они открыли вместе, и распространяет свои открытия через отчеты, публикации в Интернете, социальные сети и участие в конференциях. В настоящее время членами SDLC являются Barclays, Cerner, CH Robinson, Ericsson, hhpberlin, Microsoft, Riot Games и Scrum Alliance.

SDLC только что завершил восемь посещений объектов, включая Barclays, Cerner, CH Robinson, Ericsson, hhpberlin, Microsoft, Riot Games, BMW и Spotify.Члены встретятся в Нью-Йорке в середине сентября 2016 года, чтобы подвести итоги своих выводов.

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

Консорциум SD Learning на форуме Друкера

Отчет SDLC будет представлен на форуме Drucker под названием «Крупномасштабные организационные преобразования, способствующие быстрым бизнес-инновациям.На встрече с двумя руководителями из членов Learning Consortium. Гэри Хэмел будет обсуждать.

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

• для мгновенной, простой и персонализированной реакции в любом масштабе.

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

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

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

Сессия будет посвящена последствиям такой практики и возможностей для предпринимательства и инноваций в 21 веке.

Раскрытие информации: я — бесплатный советник и директор SDLC.

И читайте также:

Объятия гибкости HBR

Почему менеджеры ненавидят Agile

Learning Consortium Project (ноябрь 2015 г.)

Самый хранимый секрет управления на планете: Agile

Доводы против Agile: десять постоянных возражений

___________________

Следите за сообщениями Стива Деннинга в Twitter: @stevedenning

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

«Нестандартное мышление» для 21 века или ключ к успеху? Давайте перейдем к сути управления проектами Agile.

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

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

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

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

Agile — это больше, чем просто модное слово

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

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

По данным Project Management Institute, более 70% организаций внедрили Agile-подход, а Agile-проекты на 28% успешнее традиционных.

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

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

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

Что такое гибкое управление проектами?

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

Каковы четыре ценности Agile?

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

Гибкая	Не гибко
Цените людей и взаимодействия Программное обеспечение Value Working Ценность сотрудничества с клиентами Значение, реагирующее на изменение	Ценностные процессы и инструменты Полная документация по стоимости Согласование стоимости контракта Ценность в соответствии с планом

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

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

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

А теперь давайте разберемся с этим.

• Agile — это итеративная , что означает, что она выполняется частями (спринтами), при этом каждый спринт строится и совершенствуется на основе уроков предыдущего спринта. Именно здесь в игру вступает термин Scrum.Что такое скрам? Методология Scrum — это структура рабочего процесса, состоящая из спринтов и обзоров, используемая для продвижения гибкого управления проектами.
• В отличие от Scrum, который можно преобразовать в пошаговый процесс, Agile — это подход и образ мышления . Это не учебник, не перечень инструкций, не аттестат. Фактически, попытка превратить Agile в черно-белый шаблон идет вразрез со всем, чем является Agile. Это все равно, что пытаться дать кому-то пошаговый план, как быть «крутым» или играть джаз.Однако существует программное обеспечение для управления проектами, специально разработанное для повышения гибкости.
• Гибкое управление проектами — это эффективное общение посредством документации, запутанных цепочек писем или чрезмерных встреч. Согласно 12 принципам, лежащим в основе Agile Manifesto: «Самый действенный и действенный метод передачи информации команде разработчиков и внутри нее — это личное общение». Если вы можете сообщить что-то с помощью 10-секундного разговора вместо электронной почты, вам следует это сделать.
• Agile — это примерно , дающее осязаемые рабочие результаты после каждой итерации. Согласно 12 принципам: «Работающее программное обеспечение — это главный показатель прогресса». Чтобы сравнить Agile с редакционным процессом: вы доставляете черновик, а затем редактируете его на основе предложений вашего редактора. Вы не доставляете всю работу сразу в день, когда она поступает в печать.

Каковы 12 принципов гибкой разработки?

---

Согласно Agile Alliance, 12 принципов Agile следующие:

1. Удовлетворяйте клиентов за счет своевременной и непрерывной поставки ценного программного обеспечения.
2. Приветствуем изменение требований.
3. Часто доставляйте работающее программное обеспечение.
4. Ежедневно работайте вместе на протяжении всего проекта.
5. Создавайте проекты вокруг мотивированных людей, которым доверяют и которым доверяют в выполнении работы.
6. По возможности используйте личный разговор.
7. Работающее программное обеспечение — это главный показатель прогресса.
8. Поддерживайте постоянный темп бесконечно.
9. Постоянно уделяйте внимание техническому совершенству и хорошему дизайну.
10. Простота — искусство максимизировать объем незавершенной работы — очень важна.
11. Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами.
12. Подумайте о том, как стать более эффективным, затем настраивайте и регулируйте соответственно через равные промежутки времени.

Реальные примеры гибкого управления проектами

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

Итак, давайте посмотрим на несколько примеров Agile в реальном мире.

1. Еда для самостоятельного приготовления

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

Еще сыра? Меньше сыра? Другой хлеб? Гуакамоле? Нет гуакамоле? Без проблем.

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

2. Бар Apple Genius Bar

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

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

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

Вы можете сказать: «Но Apple использует процессы и инструменты, такие как iPad, на котором они делают заметки».

Да, но разговор между людьми на первом месте.

3. Бейсбол

Вы можете подумать, что это натянуто, но держитесь меня здесь.

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

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

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

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

Насколько гибка ваша команда?

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

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

Мне бы хотелось услышать, как вы определили бы Agile. Дайте мне знать в комментариях или напишите мне в Twitter @AndrewJosConrad.

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

Что такое Agile и почему это важно?

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

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

Что такое Agile?

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

Origins of Agile

Термин Agile появился довольно давно. Его можно проследить до латинского термина agilis , что означает «ловкий или быстрый», и от термина agere , что означает «приводить в движение или сохранять движение».

Итак, , что такое Agile ? Современное использование гибкой разработки в качестве метода работы можно проследить до 2001 года, когда в Сноуберд, штат Юта, прошла встреча лидеров мнений по разработке программного обеспечения. Эти идейные лидеры встретились, чтобы обсудить, как улучшить разработку программного обеспечения.

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

Лидеры мнений в области разработки программного обеспечения работали над различными альтернативными подходами к разработке, такими как экстремальное программирование, Crystal и Scrum. Неофициально эти подходы назывались легковесными методами, в отличие от предыдущих «тяжелых» методов.

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

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

Но Agile Manifesto остается основным кредо группы.

Манифест гибкой разработки программного обеспечения — 4 ценности и 12 принципов

Давайте внимательнее рассмотрим 4 ценности Agile и 12 принципов, лежащих в основе манифеста Agile.

4 Ценности Agile в манифесте

На приведенном ниже рисунке с веб-сайта Agile Manifesto показаны четыре утверждения Agile Value.

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

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

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

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

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

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

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

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

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

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

Все эти ценности в Манифесте важны, но элементы слева имеют более высокий приоритет, чем элементы справа.

12 принципов Agile

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

Для удобства я пронумеровал 12 принципов, но на веб-сайте они просто перечислены без цифр.

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

Второй принцип — приветствовать изменение требований даже на поздних стадиях разработки.В то время, когда это было написано, большинство людей были сосредоточены на контроле изменений или управлении «расширением масштабов». [Посмотрите, почему я считаю, что Scope Creep — ерунда.]

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

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

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

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

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

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

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

Принцип номер семь — работающее программное обеспечение — это основной показатель прогресса. Традиционно процент завершения использовался для измерения прогресса проектов. Процент выполнения очень ненадежен, потому что людям сложно определить процент, особенно когда он достигает 80 или 90%. Редко когда сделано 90% означает, что осталось только 10% усилий или времени. [Подробнее о правиле 90% см. В разделе «Почти готово».]

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

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

Оказывается, когда мы читаем, что пишут другие люди, есть много места для неправильного толкования.Сторонники Agile поняли, что для истинного общего понимания необходимо объединять людей. Если личный контакт невозможен, используйте доступную форму связи с максимальной пропускной способностью. Это может оказаться видеоконференцсвязь или конференц-связь. Это все равно намного лучше, чем размещение документа в SharePoint! Здесь рекомендуется использовать для них канал связи с самой высокой пропускной способностью, доступный вам.

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

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

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

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

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

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

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

Научный менеджмент и сборочная линия

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

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

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

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

Основные принципы гибкой разработки

Разработка

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

# 1 — All One Team

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

# 2 — Сотрудничество команды и клиентов

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

# 3 — Итерации с ограничением по времени

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

# 4 — Примите изменения

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

# 5 — Расширяйте возможности и доверяйте командам

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

# 6 — Непрерывное улучшение

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

# 7 — Устойчивый темп

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

У Джимми Дженлена есть видео, объясняющее эти различия, которые я рекомендую. Это называется «Краткое объяснение Agile».

Agile стал универсальным термином

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

К наиболее популярным используемым сегодня фреймворкам относятся Scrum, XP, Kanban и гибриды. Есть и другие, и многие фреймворки с годами перестали пользоваться популярностью, в том числе:

• Разработка на основе функций
• Разработка на основе поведения
• Crystal
• Экономичная разработка программного обеспечения
• Метод динамической разработки программного обеспечения
• Гибкая разработка программного обеспечения

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

Почему Agile имеет значение

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

Agile против гибкости

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

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

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

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

Ключевые преимущества гибкой разработки

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

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

Еще одним важным преимуществом, не включенным в вышеприведенный обзор, были показатели успешности проектов.Standish Group отслеживает успехи и неудачи ИТ-проектов с 1994 года. В недавнем исследовании Standish Group, включавшем данные 4000 проектов с 2013 по 2017 год, они обнаружили, что гибкие подходы в 2 раза более успешны, чем водопадные / традиционные подходы и традиционные проекты. были в 3 раза чаще провалились или были отменены.

Ключевые преимущества гибкости

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

• Повышение конкурентоспособности
• Удовлетворение клиентов
• Инновации и более быстрое внедрение изменений
• Привлекайте и удерживайте высокопроизводительных сотрудников

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

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

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

Резюме — Что такое Agile и почему это важно

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

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

Что такое гибкая методология? — Обзор гибкой разработки программного обеспечения и гибких моделей

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

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

Learn Agile

Применение методологии Agile

На протяжении большей части своей короткой истории (с 1999–2000 гг.) «Agile» преимущественно использовалась в проектах разработки программного обеспечения и ИТ-приложений. Однако с тех пор он теперь распространяется и на другие области, особенно в сфере знаний и услуг.

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

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

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

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

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

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

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

Что такое Agile Manifesto?

Agile Manifesto — это заявление об основных ценностях и принципах разработки программного обеспечения. Agile Manifesto для разработки программного обеспечения был создан в 2001 году и представляет собой декларацию 4 жизненно важных правил и 12 принципов, которые служат руководством для людей, занимающихся гибкой разработкой программного обеспечения. Его создали 17 профессионалов, которые уже практиковали гибкие методы, такие как XP, DSDM, SCRUM, FDD и т. Д., Собравшиеся в заснеженных горах американского штата Юта, созванные Кентом Беком.

Источник: LynneCazaly

4 Основные ценности Agile Manifesto

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

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

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

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

«Интеллект — это способность приспосабливаться к изменениям». — Стивен Хокинг. Щелкните, чтобы написать твит.

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

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

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

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

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

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

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

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

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

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

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

Ключевые методологии Agile

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

• Scrum
• Extreme Programming (XP)
• Adaptive Software Development (ASD)
• Dynamic Software Development Method (DSDM)
• Feature Driven Development (FDD)
• Kanban
• Разработка, управляемая поведением (BDD)

Scrum

Методология

Методология Scrum — это простая структура для работы со сложными проектами, созданная Кеном Швабером и Джеффом Сазерлендом.

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

В Scrum проекты делятся на циклы (обычно двух- или трехнедельные), называемые спринтами. Спринт представляет собой временной интервал, в рамках которого должен быть разработан набор функций. Несколько спринтов можно объединить в Релиз, в котором официальная поставка программного обеспечения / продукта осуществляется заказчику / рынку.

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

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

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

«Путешествуя по жизни, будьте открыты для сотрудничества.Другие люди и чужие идеи часто лучше ваших собственных ». — Эми Полер Щелкните для твита

Экстремальное программирование (XP)

Экстремальное программирование (XP) — или парное программирование — методология, разработанная Кентом Беком в начале 90-х годов. Эта гибкая методология ориентирована на улучшение межличностных отношений как ключ к успеху в разработке программного обеспечения. XP также ориентирована на развитие командной работы, заботу об обучении разработчиков и создание благоприятной рабочей среды.Он характеризуется тем, что разработчики работают в парах, где один разработчик программирует, а другой наблюдает; и они меняют эти роли на регулярной основе на протяжении всего спринта. Таким образом, они обеспечивают непрерывный обзор кода и обратную связь, что повышает качество кода и возможности разработчика.

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

Адаптивная разработка программного обеспечения (ASD)

Адаптивная разработка программного обеспечения (ASD) была разработана Джимом Хайсмитом и Сэмом Байером в начале 1990-х годов. Он включает в себя принципы непрерывной адаптации, то есть адаптируется к изменениям, а не борется с ними . Адаптивная разработка программного обеспечения использует динамический цикл разработки, известный как «размышлять, сотрудничать и учиться».Этот цикл посвящен постоянному обучению и интенсивному сотрудничеству между разработчиками и клиентами в связи с постоянными изменениями в деловой среде.

В отличие от большинства методологий разработки программного обеспечения, которые используют статический жизненный цикл, то есть Plan-Design-Build, ASD предлагает нелинейный итеративный жизненный цикл, где каждый цикл может повторяться и изменяться во время выполнения другого цикла. Он указывает на быструю разработку приложений ( RAD ), которая подчеркивает скорость разработки для создания высококачественного продукта, не требующего обслуживания, с максимально возможным участием пользователя.Основные характеристики ASD:

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

«В гибком проекте команда заботится о задачах, а руководитель проекта заботится о команде». — Джим Хайсмит Щелкните для твита

Метод динамической разработки программного обеспечения (DSDM)

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

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

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

Разработка, управляемая функциями (FDD)

Методология разработки, управляемой функциями (FDD), в основном ориентирована на более крупные команды с большим количеством людей, чем те, к которым обычно применяются другие гибкие методологии, такие как Scrum. FDD был разработан Джеффом Де Лука и Питером Коадом в 1997 году. Эта методология ориентирована на короткие итерации, которые позволяют осуществлять материальные поставки продукта за короткий период времени (2 недели).

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

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

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

Канбан-метод

Канбан-метод был определен Дэвидом Андерсоном в начале-середине 2000-х годов в ответ на некоторые проблемы различных гибких методов, особенно Scrum. Эти методы, пытаясь решить проблемы традиционных / водопадных методов, сами стали жертвой некоторых из тех же проблем.

2-3-недельный цикл спринта стал слишком длинным для многих бизнес-контекстов, необходимые изменения в организационной структуре (новые роли и обязанности) и процессы управления / планирования проекта стали слишком тяжелыми для организаций, и многие команды оказались невыполнение обязательств даже на уровне спринта по объему и качеству. Для большинства организаций внедрение этих методов стало очень разрушительным.

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

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

Канбан определяется как высокоэффективная и действенная производственная система. Истоки методологии Канбан лежат в производственных процессах «точно в срок» (JIT), разработанных Toyota, в которых карты использовались для определения материальных потребностей в производственной цепочке.Вы можете узнать больше о канбане здесь: https://www.digite.com/what-is-kanban/

Behavior Driven Development (BDD)

Behavior Driven Development (BDD) — это методология гибкой разработки, ориентированная на поведение. Он был создан Дэном Нортом в 2003 году как эволюция методологии TDD. Дэн Норт стремился объединить нетехнических людей в процессе создания технической функциональности системы. Бывает, что при разработке программного обеспечения мы невольно не включаем бизнес-концепции, представленные в функциональности, что может привести к повторяющимся и даже серьезным ошибкам.

Источник: Johnfergusonsmart.com

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

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

«Эффективное общение — это на 20% то, что вы знаете, и на 80%, как вы относитесь к тому, что знаете». — Джим Рон Щелкните, чтобы написать твиттер

Сводка

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

Готовы ли вы стать Agile? Digite предлагает широкий спектр продуктов для гибкой трансформации предприятия.

Свяжитесь с нами , и мы поможем вам с преобразованием.

No related posts.