Что такое аджайл: Что такое 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. Фактически, все договорённости и правила команды в 10-11 человек, текущие задачи на пару недель, цели, а также стратегические планы легко могут поместиться на 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 в России от 2017 года.

Как объяснить бабушке, что такое Agile за 15 минут с картинками / Хабр

«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.»
— закон Хофштадтера
Самый просматриваемый ролик на YouTube по теме agile. 744 625 просмотров на момент публикации данной статьи. Легкий стиль изложения, картинки и всего 15 минут — лучшее что я видел. TED отдыхает.

Роли

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

Пропускная способность

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

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

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

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

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

Что произойдет, если мы будем делать все, о чем они нас просят? У нас будет перегруз.

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

Scrum и XP в этом случае используют метод “вчерашняя погода”. Команда говорит: “За последнее время мы делали 4-6 фич в неделю, какие 4-6 фич мы будем делать на следующей неделе?”

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

Kanban рекомендует ограничиться несколькими задачами — WIP limit. Допустим команда решает, что 5 — это приемлемое количество пользовательских историй, над которыми они смогут работать одновременно без перегруза, не перескакивая с одной на другую.

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

Этой очередью тоже необходимо управлять.Если заинтересованные лица запрашивают 10 историй в неделю, а команда реализует 4-6 историй, то эта очередь будет становиться все больше и больше. И скоро ваш Backlog будет расписан на полгода вперед. То есть одна история будет ждать выхода 6 месяцев.

Есть только один способ держать список задач под контролем — это слово “нет”

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

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

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

Принятие решений

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

Как соотносится размер истории и ее ценность? Никак. Больше не значит лучше. Ценность и сложность задачи — вот что помогает Пэт расставлять приоритеты.

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

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

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

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

Владелец ИТ-продукта должен постоянно со всеми общаться

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

Баланс между сложностью разработки и ценностью пользовательской истории

На ранней стадии балансу угрожает неопределенность и сразу несколько рисков.

Риски

Бизнес риск: «Правильную ли вещь мы делаем?»

Социальный риск: «Сможем ли мы сделать то что нужно?»

Технический риск: «Будет ли проект работать на данной платформе?»

Риски со стоимостью и сроками реализации: «Успеем ли и хватит ли денег?»

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

Компромисс между ценностями знания и ценностями для клиента

С точки зрения заказчика кривая выглядит вот так:

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

Компромисс между краткосрочным и долгосрочным мышлением

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

Делать правильные вещи, делать вещи правильно или делать быстро?

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

или

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

или

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

Между ролями в Scrum существует здоровое противостояние

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

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

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

Продукт никогда не может быть полностью завершен, потому что ему постоянно нужны изменения. Когда команда начинает работу над новым продуктом, что происходит со старым? Передача продукта от одной команды к другой — очень затратно и рискованно. Обычно команда поддерживает старый продукт, разрабатывая новый. Поэтому скорее понятие “Backlog” относится не к продукту а к команде. Backlog — это список вещей, которые хочет владелец продукта от команды. И набор историй для разных продуктов. Владельце продукта нужно постоянно выбирать актуальные для реализации.

График уничтожения историй

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

Предположим, заинтересованное лицо спрашивает, когда вот эта фича будет сделана?

Это вопрос с фиксированным содержанием и неопределенным сроком. Для ответа Пэт использует две линии тренда. Ответ — в апреле или мае.
Заинтересованное лицо спрашивает Пэт: «Сколько будет сделано к рождеству?» Это вопрос с фиксированным сроком и неопределенным содержанием. Линии тренда отсекают на вертикальной шкале вероятный отрезок того, что успеют реализовать.
Заинтересованное лицо спрашивает :«Успеем ли мы сделать вот эти фичи к рождеству?» Это вопрос с фиксированными временными рамками и фиксированным содержанием. Ориентируясь на тренды, Пэт отвечает: «Нет». Добавляя: «К рождеству мы успеем сделать столько, а вот столько времени нам понадобится чтобы завершить всю эту работу полностью.»

Обычно лучше уменьшать содержимое проекта, чем увеличивать время. Если мы уменьшаем содержание, у нас будет возможность отодвинуть сроки. Мы можем выпустить кое-что здесь, а остальное — позже.

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

Несколько команд

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

Большая картинка

Исходник — Agile Product Ownership in a nutshell

видео на английском

видео на русском

Что такое Аджайл и Скрам — Справочная

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

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

Что такое Аджайл

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

Аджайл-коуч — специалист, который учит ценностям и помогает компаниям расти. Такого коуча можно найти в консалтинговом агентстве. Например — Unusual Concepts или Scrum Trek.

Аджайл-коуч расскажет о четырёх принципах:

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

Игорь Беляк, тимлид команды разработки интеллектуальных решений DIRECTUM:

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

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

Как применять Аджайл

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

Влада Беганова, скрам-мастер в команде разработки банка Точка:

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

Ценности и установки Аджайл выполняются, когда есть чёткие правила. Такие правила называются фреймворками. Фреймворк — каркас, на котором строится рабочий процесс. Фреймворков, позволяющих внедрить Аджайл, несколько: Скрам, Канбан, Нексус. Новичкам проще использовать Скрам: у него есть чёткий перечень правил. Рассказываем, как применять Скрам, чтобы получить результат.

Инструменты Скрама

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

Распределение ролей

Скрам работает, когда есть распределение ролей. Всего их три.

Команда. Это самоорганизованная группа из 3−9 человек. Вклад отдельного сотрудника не оценивается. Важно только то, какого результата добилась команда совместными усилиями.

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

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

Бэклог продукта

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

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

Бэклог спринта

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

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

Когда бэклог утверждён, вносить в него новые задачи или убирать старые — нельзя.

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

Скрам-доска и Trello

Главный инструмент — скрам-доска. Скрам-доска используется при составлении бэклога спринта или продукта. Удобно, когда она разделена на три колонки — «Пообещали», «В работе», «Сделали». Ежедневно команда собирается и смотрит, какие задачи закрыты, а над какими ещё надо работать. Например, сегодня стикер с надписью «Придумать дизайн светодиодного светильника» будет в работе, а завтра он переместится в категорию «Сделали».

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

Что значит быть Agile? / Хабр

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

Например, юнит-тестирование, покер планирования, ежедневные стендапы стали считаться Agile практиками.

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

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

Данная статья – попытка переосмыслить известные мне Agile практики, сформулировать простые и четкие критерии того, какую практику можно считать Agile, а какую нет.

Построю статью следующим образом. Сначала предложу критерии, затем протестирую их на примерах.

Критерии

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

Креативные профессионалы

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

Agile поощряет обучение и профессиональный рост.

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

Эффективные коммуникации

Эффективные – это те коммуникации, которые ведут к принятию правильных решений.

Главный инструмент Agile – живое общение лицом к лицу (face-to-face). При этом задействуются все каналы передачи информации, доступные человеку, причем в обоих направлениях.

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

Прозрачность, полное раскрытие информации без страха быть наказанным.

Ценность для заказчика/пользователя

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

Agile старается исключать/минимизировать всё, что ценности не приносит (eliminate waste).

Обратная связь

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

Важнейший фактор – оперативность обратной связи.

Соответствие ценностей Agile Манифеста предложенным критериям

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

Регулярный рефакторинг кода

проясняет архитектуру, открывает путь к творчеству, обучению и совершенствованию

облегчает дальнейшее развитие продукта, ускоряет внесение изменений (eliminate waste)

замыкает петлю обратной связи: выявили проблемы – решаем их

Настольный теннис в офисе

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

Конструктивный конфликт

разносторонняя оценка, принятие эффективных решений посредством двусторонней коммуникации

Кросс-функциональные команды

нет потерь времени при передаче задач между командами

разносторонняя оценка, принятие решений, учитывающих все аспекты

Ежедневные стендапы

быстрая обратная связь

прозрачность, взаимопомощь

Информационные радиаторы (канбан-доски, burnup charts)

прозрачность

Бэклог, user stories

наиболее ценные задачи делаем в первую очередь

механизм обратной связи заложен в приемку каждой user story; декомпозиция сторей до небольшого размера повышает оперативность обратной связи

Planning Poker (быстрая коллективная оценка задач)

предварительное обсуждение задач и плана работ, прозрачность

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

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

Планирование спринта

обсуждение задач непосредственно перед разработкой

наиболее ценные задачи делаем в первую очередь

обратная связь о том, что может или не может быть сделано прямо сейчас

Открытые рабочие пространства (open space)

оперативный обмен информацией, фоновое восприятие и вычленение релевантной информации

Разработка короткими итерациями (спринтами)

частое планирование и частое подведение итогов

Парное программирование

наиболее оперативная обратная связь – в момент написания кода

Автоматизированное тестирование, юнит-тесты, непрерывная интеграция и поставка (CI/CD)

оперативная обратная связь

Definition of Done

выполнение DoD – важная точка обратной связи

DoD обычно включает поставку ценности клиенту

Не Agile практики

Работа по большому ТЗ, подписанному заказчиком

существенно откладывает или даже блокирует обратную связь

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

блокирует открытое общение с заказчиком, создает почву для конфликтов с ним

Поиск виноватого, штрафование сотрудников

демотивирует конкретного человека, подрывает доверие в команде; штраф – сильнейший демотиватор

вместо обмена мнениями о проблеме и способах её решения, идет поиск виноватого

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

Персональное назначение задач (тимлидом / менеджером проекта)

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

отсутствие обсуждения не способствует эффективному принятию решений

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

способствует отстраненности, не фокусирует команду на целях и ценностях клиента

Логирование времени

демотивирует сотрудников

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

требует дополнительных усилий, не приносящих ценности

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

Технический долг

рутина (сложность кода, долгое устранение ошибок) блокирует творчество

обслуживание технического долга – это расточительство, оно не приносит ценности, наоборот, отнимает её

Попытки заказчика/менеджера уменьшить оценки трудозатрат, определенные разработчиками

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

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

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

Заключение

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

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

Напишите, какие Agile или не-Agile практики не соответствуют, на ваш взгляд, предложенным критериям. Предложите свои критерии.

AGILE – гибкая система управления проектами

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

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

Метод Agile: определение и краткая история

Как бы непривычно это ни звучало, но серьезно разрабатывать программное обеспечение и управлять проектами начали уже в 70-х годах прошлого века. Именно в 1970 году американский ученый-компьютерщик Уинстон Ройс составил документ, называвшийся «Управление развитием крупных программных систем». В нем он приводил критику последовательной разработки, указывая на то, что разработка программного обеспечения не должна походить на работу сборочной линии (как, например, делается в автомобильном производстве), где новые детали по очереди добавляются в последовательные фазы.

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

На основе этого в 90-х удалось создать комплекс гибких методов разработки ПО, способных заменить сложные и трудоемкие методы. Происходило это так:

• В 1991 году появился метод быстрой разработки приложений RAD
• В 1994 году появился метод разработки динамических систем DSDM
• В 1995 году появилась платформа (фреймворк) гибкой разработки Scrum
• В 1996 году появилась гибкая методология разработки Crystal Clear, а также экстремальное программирование XP
• В 1997 году появилась итеративная методология разработки ПО FDD

Все вместе эти методы объединились под общим названием гибких методов разработки ПО.

Четыре года спустя – в 2001 году в штате Юта (США) на курорте Snowbird собрались семнадцать разработчиков программного обеспечения. В результате обсуждения методов разработки был опубликован «Манифест о гибкой разработке программного обеспечения Agile» (в переводе с английского понятие «agile» означает «подвижный», «проворный» или «быстрый», но в большинстве случаев его переводят именно как «гибкий»). Он и задал темп всей дальнейшей работе над созданием ПО.

Манифест Agile

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

Идеи Agile:

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

Принципы Agile:

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

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

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

Ключевые моменты в применении Agile

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

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

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

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

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

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

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

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

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

• Что я делал вчера?
• Чем я буду занят сегодня?
• Что мешает мне работать?

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

1. Четко обозначается значение проекта
2. В процессе реализации активно участвует клиент
3. Общий объем работ выполняется пошагово
4. Ориентироваться следует на конкретный результат
5. Численность одной рабочей группы: от 7 до 9 человек

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

Примеры: правительство Новой Зеландии, правительство Нигерии, Норвежский пенсионный фонд, компания Return Path (программное обеспечение), компания Oreo (производство печенья), компания Aviasales (крупнейший поисковик авиабилетов), компания Hewlett-Packard (крупнейшая американская IT-компания), «Сбербанк» (наверное, знаете, что это).

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

Популярные методы управления проектами

Существует немало методов проект-менеджмента, которые применяются разными современными компаниями. Но самыми известными и востребованными среди них по праву считаются Scrum (Скрам) и Kanban (Канбан).

Метод Scrum

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

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

• Определяются объемы работы
• Каждый день проводятся 15-минутные встречи, чтобы члены команды могли скорректировать свою работу и подвести промежуточные итоги
• Демонстрируются полученные результаты
• Спринты обсуждаются для поиска удачных и неудачных решений и действий

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

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

Метод Kanban

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

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

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

Это лишь примеры основных методов управления проектами, основанных на Agile. Но не стоит пренебрегать и другими методами, такими как PRINCE2, Lean, Six Sigma, XP, CCPM, ECM, Waterfall и другие. К тому же у Аджайл, наряду с преимуществами, есть и некоторые недостатки.

Плюсы и минусы Agile

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

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

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

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

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

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

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

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

Внедрение Agile

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

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

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

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

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

Заключение

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

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

что это и зачем нужно

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

Что такое Аджайл

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

Буддисты верят, что могут достичь просветления. Они медитируют, стараются быть умеренными и не причиняют вреда другим.

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

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

Как появился Аджайл

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

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

Чтобы найти формулу успешных продуктов, в 2001 году семнадцать практиков современных подходов собрались в маленькой горной деревушке Сноубёрд. Они обсудили свои стратегии разработки и сделали открытие: подходы у всех разные, но общие идеи совпадают. Эти идеи легли в основу «гибкой» философии, которую назвали Аджайлом. Их записали в итоговых документах: «Манифесте» и «Принципах Аджайла».

В чем суть философии Аджайла

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

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

Аджайл — это быть командой профессионалов, которым не нужен начальник

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

Аджайл — это работа вместе с клиентом, эксперименты и готовность изменить план

Результаты пекарен будут кардинально различаться: непредсказуемые у одних и гарантированно хорошие у других:

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

Чтобы выстроить работу в духе аджайла пекарня из нашего примера использовала в работе постулаты «Манифеста»:

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

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

Что дает Аджайл

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

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

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

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

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

Аджайл помогает быть счастливее: видеть в работе дело жизни и получать от нее удовольствие.

При чем здесь Скрам и Канбан

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

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

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

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

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

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

Лучший вариант — соединить философию с практикой и получить предсказуемо хороший результат.

Шпаргалка

agilebasics.ru

Agile/Scrum для начинающих. Что такое гибкая методология?

Что такое Agile и Scrum?

Что такое Agile?

В переводе с английского языка «agile» означает «живой, подвижный», но переводят его чаще как «гибкий». В отрасли разработки программного обеспечения этот термин появился в начале 2000-х годов, когда в штате Юта был издан «Манифест гибкой разработки ПО». С тех пор под «agile» понимают набор подходов по “гибкой” разработке программного обеспечения.

Agile Manifest

Суть agile-подхода изложена в “манифесте”, но для заказчика ее можно коротко сформулировать так:

• разработка ведется короткими циклами (итерациями), продолжительностью 1-4 недели;
• в конце каждой итерации заказчик получает ценное для него приложение (или его часть), которое можно использовать в бизнесе;
• команда разработки сотрудничает с Заказчиком в ходе всего проекта;
• изменения в проекте приветствуются и быстро включаются в работу.

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

Основополагающие принципы Agile.

Краткое видео о том, что такое Scrum (english).

Что такое Scrum?

Scrum – это одна из нескольких методологий гибкой разработки ПО:

• • Scrum
  • Lean
  • Feature Driving Development
  • Extreme Programming

Scrum процесс на одном листе

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

Артефакты в Scrum

В скрам используется всего четыре артефакта:

• Product Backlog
• Sprint Backlog
• Sprint Goal
• Sprint Burndown Chart.

Я рекомендую вам посетить наш тренинг “Scrum для проектных команд“. Тренинг помогает изучить Scrum-процесс от начала и до последних нюансов.

Product backlog:

• Это список всех требований, которые нужно сделать по проекту. Когда в Backlog’e нет требований, проект считается завершенным.
• Все требования описаны по единому шаблону, который называют User Story (пользовательская история).
• Требования составлены так, что очевидно и понятно, какую ценность они представляют для пользователя
• Требования отсортированы по приоритетам, которые пересматриваются каждый спринт.

На снимке ниже представлен Backlog проекта. Команда проекта выбрала 2 требования в Sprint#3.

Project Backlog (JIRA)

Sprint backlog:

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

Sprint Backlog – это обязательство команды: что они должны выполнить за ближайшие 2 недели. Каждое требование разделено на задачи, которые представлены на Kanban-доске.

Kanban Доска в Спринте

Sprint Goal

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

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

Sprint Burndown Chart

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

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

Burndown диаграмма в Jira

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

Роли в Scrum

В скрам используется всего три роли:

• Product Owner
• Scrum Master
• Team.

Роль Product Owner

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

Product Owner – это представитель подразделения, которое владеет разрабатываемым продуктом. Например в банке это может быть Департамент карточных продуктов. Правильно определить Product Ownera не просто, т.к. эта роль требует сочетания следующих качеств:

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

В некоторых случаях допустимо назначить более одного человека на роль Product Owner. Но в этом случае необходимо назначить среди них “главного”, который будет авторизовать требования в Bcaklog’e и лично расставлять приоритеты.

Роль Scrum Master

• следит за корректным применением принципов Agile и процессов (ритуалов) Scrum
• организует работу команды и обеспечивает её всем необходимым
• защищает команду, несёт ответственность за её эффективность
• только один человек.

Очень сложная роль. В классическом project management есть Руководитель проекта. В Scrum такая роль не предусмотрена. Лучшим синонимом роли Scrum Master будет “администратор”. Скрам Мастер организовывает работу команды проекта, но не вмешивается в её работу.

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

Тем не менее, если скрам-процесс проходит с нарушениями (кто-либо из команды опаздывает на daily-meeting), то мастер должен вмешаться и исправить ситуацию.

Функции Scrum Master’a существенно шире, но чтобы пояснить их все нужна отдельная статья. Пишите в комментариях, если таковая нужна.

Team (команда проекта)

• кросс-функциональная
• взаимозаменяемая
• самоорганизующаяся
• с фиксированным составом (в ходе спринта)
• 4-10 человек.

Команда отвечает за разработку продукта итерациями (спринтами). Команда определяет самостоятельно:

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

Команда НЕ принимает решений:

• какие требования являются приоритетными – это делает Product Owner.

На снимке ниже команда проекта проводит обязательный “ритуал” – Daily Meeting (см. ниже).

Команда проводит “ритуал” Daily Meeting

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

Ритуалы (процессы в Scrum)

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

Ритуалы в скрам это:

• Sprint Planning Meeting
• Daily Meeting
• Sprint Review
• Retrospective

Sprint Planning Meeting (встреча по планированию спринта)

• выполняется всей командой перед началом спринта
• команда выбирает требования из Product Backlog и формирует Sprint Backlog
• если требуется учесть взаимосвязи между операциями, то это делается здесь
• команда декомпозирует требования на задачи (tasks)
• каждая задача проходит оценку в трудозатратах или универсальных единицах
• во время встречи Product Owner отвечает на вопросы команды.

Встреча, которая проводится перед началом каждого спринта. Структура встречи:

• представление и пояснение Product Owner’ом списка требований
• вопросы со стороны команды
• /рекомендуется перерыв/
• декомпозиция требований на задачи (tasks)
• оценка задач по методу Planning Poker.

Встреча простая по сути, но крайне сложная по содержанию. В начале проекта может занимать 5-6 часов. И только после 3-4 спринта встреча становится более оперативной и длится 2-3 часа. Крепитесь.

Daily Meeting (ежедневная встреча команды).

Из названия понятно, что встреча проводится ежедневно. Основные принципы:

• проходит ежедневно и только в одно и то же время;
• встреча проходит только стоя;
• поэтому длительность встречи не более 15 минут;
• чтобы успеть каждый должен ответить всего на 3 вопроса: что я делал вчера, чем я занимаюсь сегодня, какие есть проблемы?

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

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

Встреча команды эффективно проводить напротив Kanban доски, на которой отражены все задачи спринта.

Kanban Board во время спринта

Sprint Review – сдача спринта Product Owner

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

Ценность Scrum для обычного заказчика во многом состоит в том, что результат работ (плохой или отличный, не важно) будет продемонстрирован в любом случае. Это знает и команда и Product Owner и другие заинтересованные лица. Если команда не проводит демонстрацию (иное название Sprint Review), то это дискредитирует все преимущества гибких процессов.

Структура встречи:

• команда зачитывает требования из Sprint Backlog
• по каждому критерию приемки происходит демонстрация полученных результатов
• каждый вопрос со стороны Product Owner’а записывается, чтобы иметь возможность ответить на них позже
• каждое новое требование Product Owner’a выписывается, чтобы позже включить его в Product Backlog.

На встрече могут присутствовать любые сотрудники организации или просто заинтересованные лица. Важно, чтобы право голоса имели только участники Scrum процесса (Produt Owner, Team, Scrum Master).

Никаких презентаций в PowerPoint на встрече, если вы правильно меня поняли!

Retrospective

Ритуал, который направлен на обмен опытом внутри команды. Встреча проводится после Sprint Review. На встрече присутствует вся команда и Scrum Master. На встрече может присутствовать Produt Owner, если считает нужным.

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

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

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

Почему появился Agile?

Теперь немного слов о том, как и зачем появился этот подход? История возникновения этого подхода стала ответом на запросы отрасли:

1. Заказчик не может сформировать четкие требования к ПО;
2. Новые технологии усилили конкуренцию и потребовали оперативного применения в бизнесе;
3. Заказчики и разработчики ПО не удовлетворены процессом взаимодействия.

#1 Заказчик не может сформировать четкие требования к ПО

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

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

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

В традиционных «водопадных» моделях руководитель проекта минимизирует изменения в проекте, используя для этого отдельные процессы – управление изменениями. Но если требования будут меняться раз в месяц, то управление изменениями становится трудоемким и замедляет ход проекта.

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

#2 Новые технологии усилили конкуренцию и потребовали оперативного применения в бизнесе

К середине 90-х разрабатываемое ПО было в основном десктопным и его требовалось устанавливать на каждый отдельный компьютер (например, MS Word). С появлением веб-приложений внедрение новой функциональности стало происходить быстрее: требовалось развернуть приложение только на сервере и все пользователи получали к нему доступ. Эта инновация серьезно усилила конкуренцию между компаниями: тот, кто применил новую технологию раньше других – выигрывает рынок и клиентов.

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

#3 Заказчики и разработчики не удовлетворены процессом взаимодействия

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

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

При этом agile не отказывается от формулирования требований. Заказчик (в agile – владелец продукта, product owner) предъявляет требования в упрощенном виде и на сценариях работы пользователей.

Резюме

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

0
91
100

38

Закрыть

Большое спасибо, что нашли время написать отзыв!

• Содержание статьи

• Актуальность информации

• Содержание статьи

• Актуальность информации

Спасибо, для новичков отличный старт!

• Содержание статьи

• Актуальность информации

Спасибо, доступно, общую картину получил

• Содержание статьи

• Актуальность информации

Очень познавательно

• Содержание статьи

• Актуальность информации

Понятно,доступно,емко,спасибо.

• Содержание статьи

• Актуальность информации

Спасибо! Все изложено в доступной форме!

• Содержание статьи

• Актуальность информации

Очень содержательно и последовательно!

• Содержание статьи

• Актуальность информации

Thanks a lot for your article! It was very helpful to me.

• Содержание статьи

• Актуальность информации

• Содержание статьи

• Актуальность информации

• Содержание статьи

• Актуальность информации

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Каковы 12 принципов Agile?

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

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

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

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

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

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

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

.

Что такое Agile? — Azure DevOps

• 03.10.2017
• 4 минуты на чтение

В этой статье

Автор: Аарон Бьорк

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

Мы пришли к стоимости:

• Отдельные лица и взаимодействие над процессами и инструментами
• Рабочее программное обеспечение поверх исчерпывающей документации
• Сотрудничество с клиентами в ходе переговоров по контракту
• Реагирование на изменение в соответствии с планом

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

Гибкие методы и практики

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

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

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

Что не такое Agile

По мере того, как agile набирает популярность, многие стереотипы и / или
неверные толкования бросили тень на его
эффективность.Легко сказать « Да, мы делаем Agile » без каких-либо
подотчетность. Учитывая это, давайте посмотрим на некоторые вещи, которые Agile
нет.

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

«Планы бесполезны, но планирование — это все». — Дуайт Д.
Эйзенхауэр

• Agile — не оправдание отсутствия дорожной карты.У этого есть
  вероятно, нанесли наибольший вред гибкому движению в целом.
  Организации и команды, следующие Agile-подходу, абсолютно знают
  куда они идут … и желаемых результатов
  достичь. Признание изменений как части процесса (гибкая
  подход) отличается от поворота в новом направлении каждую неделю,
  спринт, или месяц.
• Agile — это разработка без спецификаций. Это необходимо в
  любой проект, который поможет вашей команде понять, «почему» и «как», работа будет
  случиться. Гибкий подход к спецификациям включает в себя обеспечение соответствия спецификациям.
  «Подходящего размера» и соответствующим образом отражать то, как команда будет
  последовательность и выполнение работ.

Почему Agile?

Так зачем кому-то рассматривать гибкий подход? Понятно правила
участие в создании программного обеспечения в корне изменилось в
последние 10-15 лет. Многие занятия похожи, но пейзаж
и среды, в которых мы их применяем, заметно отличаются. Рассмотреть возможность
на мгновение, каково покупать программное обеспечение сегодня… по сравнению с
начало 2000-х. Когда вы в последний раз ездили в магазин покупать
программного обеспечения? Подумайте, как вы собираете отзывы клиентов, использующих
ваши продукты.Как мы поняли, что люди думают о нашем
программное обеспечение до социальных сетей? Наконец, подумайте, как часто вы хотите
для обновления и улучшения поставляемого вами программного обеспечения. Доставка обновлений
один раз в год — это не рецепт победы. Диего Форрестера
Лучше всего об этом сказали Ло Гуидиче и Дэйв Уэст в статье Transforming
Подача заявки (февраль 2011 г.).

«Фирмы сегодня переживают гораздо более высокую скорость изменения бизнеса.
Рыночные возможности появляются или исчезают через месяцы или недели вместо
лет.«- Диего Ло Гуидиче и Дэйв Уэст, Forrester

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

Начните работу с бесплатными гибкими инструментами в Azure Boards.

.

Что такое гибкая разработка программного обеспечения?

До 2001 г. — Практика и методы развиваются независимо на основе опыта

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

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

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

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

Люди, создавшие эти методологии, посчитали, что другие могут быть заинтересованы в получении некоторых из тех же преимуществ, что и они, поэтому они создали структуру для распространения идей среди других команд в других организациях и контекстах. Именно здесь и начали появляться такие фреймворки, как Scrum, Extreme Programing, Feature-Driven Development (FDD) и Dynamic Systems Development Method (DSDM).

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

2001 — Автор манифеста Agile

Не существовало единого способа описания этих различных способов разработки программного обеспечения, пока группа из 17 человек не подумала: «Мы все применяем разные подходы к разработке программного обеспечения. Мы должны собраться вместе и посмотреть, есть ли общие черты в том, о чем мы думаем ». Результатом стала встреча на горнолыжном курорте в Сноуберд, штат Юта, в 2001 году.

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

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

Спустя несколько месяцев авторы расширили идеи Agile-манифеста с помощью 12 принципов, лежащих в основе Agile-манифеста.

Некоторые авторы, в том числе Мартин Фаулер, Дэйв Томас, Джим Хайсмит и Боб Мартин, написали свои воспоминания о написании Agile Manifesto. 16 из 17 авторов встретились на Agile2011 и поделились своими воспоминаниями о мероприятии и своими взглядами на состояние Agile на тот момент.

После 2001 г. — Принятие началось массово, стало мейнстримом

После того, как авторы вернулись из Snowbird, Уорд Каннингем опубликовал Agile Manifesto, а затем 12 принципов онлайн на AgileManifesto.орг. Люди могли выйти в Интернет и подписать его, чтобы выразить свою поддержку.

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

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

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

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

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

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

.

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

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

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

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

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

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

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

.