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

Как объяснить бабушке, что такое 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-подход и зачем он нужен бизнесу? — статья в блоге 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 на заводе? Agile методология.

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

Скажи Agile

«Что с этим нам делать то, у нас из программирования только сайт?»

В итоге примерно для 100% компаний Agile смахивает на шарлатанство.

Но вот парадокс — в мире 77% компаний*, использующих Agile в проектах, занимаются совсем не разработкой программного обеспечения.

статистика использования Agile

*Из большого ежегодного опроса компаний от VersionOne

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

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

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

Команда в игре «Что? Где? Когда?» существует по принципам Agile. Взаимодействиям отдана ключевая роль. Капитан выполняет роль заказчика продукта (верного ответа), 2-3 эрудита перебирают массивы информации, кто-то следит за временем, есть человек, который анализирует, задает вопросы и побуждает общение, любой может высказаться и привести к результату или все провалить, за пределами игры есть разбор полетов (ретроспектива).

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

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

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

Но. Даже если вы веб-студия и для вас это тысячный сайт, для клиента это первый раз. И его желания останутся неопределенностью до самого конца. Многие студии делают 3-4 варианта главной страницы и закладывают неделю на непредвиденные доработки. У всех, кого я знаю, работа разбита на итерации, после каждого есть демонстрация и обсуждение. Общение с заказчиком важнее подписанного контракта.

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

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

Итого ключевые ценности Agile (манифест):

  • свободное взаимодействие в команде
  • результативность проекта (классный продукт)
  • партнерское общение с клиентом
  • готовность к изменениям

Что такое команды с ролями?

В привычной команде есть две роли: Начальник и Подчиненный, один умный другой дурак. В Agile принципиально важны три: Заказчик продукта, Методист, Участник команды.

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

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

Со стороны гибкая команда от привычной отличается именно наличием или отсутствием так называемого повествовательного диалога (narrative collaboration).
Если идет обсуждение вопроса «Как реализовать продукт?» на всех уровнях, значит команда гибкая. Если ищут кто виноват, что не выполнен список конкретных задач, значит все как обычно.

Главный вопрос: «Как управлять ресурсами когда все так гибко?»

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

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

Есть несколько важных принципов и методов, явно направленных именно на прогнозирование ресурсов:

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

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

3. Короткие итерации (спринты). Этот подход, как никакой другой позволяет компаниям пробовать что-то из Agile. Руководство согласно на промежуточный результат через пару недель без того, чтобы влезать и всем проставлять задачи. Согласиться на такой режим работы на полгода было бы невозможно.
Спринт (итерация) — это отрезок времени в несколько недель. У нас чаще всего это 2 недели. Самое важное в спринте — это определение того, какой промежуточный результат должен быть получен. Этим результатом хорошо называть итерацию, например, «Выпуск досок с правами» или «Выпустить сайт на тест». Если работа идет по отрезкам времени, но каждый отрезок не приводит к какому-то конкретному результату, то это уже не итерационный подход.

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

статистика использования Agile

Мы используем третий, но оценки бывают только 1h, 2h, 4h, 8h.

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

5. Burndown chart (график сгорания)
Очень простая вещь — это график с двумя линиями; первая — сколько времени сгорело и это всегда прямая, на второй — сколько задач в пересчете на ресурсы закрыто и тут возможны колебания. Фактически это графический ответ на вопрос идет ли команда по плану или отстает.

статистика использования Agile

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

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

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

Топ 5 самых популярных Agile-практик понятных всем

Еще раз подчеркну, Agile на базовом уровне применения — это просто. Нет никаких сверхсложных приемов, которые надо долго изучать. Ниже для примера приведено 5 самых популярных практик (по данным все того же опроса от VersionOne)

Agile методология

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

1. Итерационное планирование — спринты (90% команд используют)
Работать небольшими забегами с промежуточным результатом — хорошая практика. Спринт — это несколько недель. Слишком короткие или слишком длинные отрезки — плохо. Одинаковый интервал на все случаи жизни тоже не годится. У спринта должна быть максимально точная цель, исходя из этого и определяется длительность.
Самый частый ошибкой является то, что команды привыкают просто расписывать задачи раз в две недели, теряются процессы постановки промежуточных целей и подведение итогов в конце. Работа сваливается в обычный поток задач с обновлением раз в спринт. Проблему должен решать методист.

2. Ежедневные планерки (88% команд используют)
Задача — чтобы каждый день команда подтверждала единое направление движение всех участников.
По классическому описанию каждый в команде раскрывает три вопроса:

  • Что сделано к этому моменту из спринта?
  • Что планируется на сегодня?
  • Какие проблемы возникли или что мешает?

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

3. Ретроспективы (83% команд используют)
Совещание в конце итерации. Обсуждение, что получилось, а что не очень. Самая важная цель — сделать выводы о том, как меняться.
Заказчику продукта — о том как лучше показывать ожидания пользователей, методисту — о том, как побуждать диалог и выполнять договоренности выбранных подходов, команде — о том, как при оценках учитывать новые открывающиеся факторы.
Как правило ретроспективы проходят весело — итерация-то закончилась, можно выдохнуть и обсудить итоги. Хорошая практика что-нибудь пить или есть в перерывах этого процесса.

4. Итерационные показы (81% команд используют)
Это демонстрация от команды раз в несколько итераций результатов проекта, как правило в виде выступления. Главный смысл в том, чтобы была «сессия» и ничего страшного, если это станет похоже на отчетность перед руководством.
Главная трудность в том, чтобы собрался кто-то кроме команды, да еще и понимал смысл происходящего. По нашей практике приживается только при очень крутом руководстве.

5. Короткие итерации (71% команд используют)
Смысл в том, что нужно постоянно стараться сокращать цикл получения маленьких промежуточных результатов. Если этого не делать, циклы будут естественным образом расти или будет постоянными, независимо от промежуточных целей. Чем короче цикл, тем меньше ошибок при итерационном планировании.
Это задача методиста, стоит вспоминать про это хотя бы раз в полгода.

Как понять ведется ли проект по Agile-методологии или еще нет?

Диаграмма того, сколько компаний меняют Agile под себя выглядит так:

Agile методология

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

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

Agile методология

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

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

Методология agile: особенности и условия внедрения


Вопросы, рассмотренные в материале:

  • Что такое методология agile

  • Какие проблемы возникаю с применением методологии agile

  • Что нужно изменить в фирме для внедрения методологии agile

  • Как выбрать консультанта по методологии agile


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

Что такое методология agile


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


Able to move quickly and easily.


Able to think and understand quickly.


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




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

  • ориентируют команду на удовлетворение нужд клиентов;

  • упрощают бизнес-процессы;

  • делят рабочий процесс на короткие циклы;

  • активно используют обратную связь;

  • подразумевают расширение полномочий сотрудников;

  • основываются на гуманистических принципах;

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


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


В рамках методологии agile выделяют два различных подхода – scrum и kanban.


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


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


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




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


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



Топ-3 статей, которые будут полезны каждому руководителю:

9 проблем, связанных с методологией agile

  1. Привычка к роли


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

  2. Привычка к документации


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

  3. Новая команда


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




  4. Проблемы с общением


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

  5. Давление по срокам


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

  6. Креативность


    7. Не все задачи в проекте одинаково интересны, к тому же разработчики нередко пытаются внедрить решение, привлекательное с технической точки зрения, но способное навредить общему результату. С методологией agile хорошо сочетаются принципы КISS (keep it simple, stupid) и YAGNI (you ain’t gonna need it). При выборе из нескольких вариантов решений предпочтение стоит отдавать самому простому. Чтобы научить команду придерживаться этого правила, достаточно один раз позволить специалистам совершить ошибку, затем подробно разобрать ее и объяснить, почему так делать нельзя. Практически в каждом проекте есть поле для экспериментов – дополнительные исследовательские задачи, в которых можно применять «красивые» решения без вреда для конечной цели работы.

  7. Оценка времени


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

  8. Проблема с менеджментом


    9. Руководство надеется получить к указанному сроку определенные результаты работы, но при выборе методологии agile для управления проектами 100-процентного выполнения плана ожидать не стоит, в приоритете решение только главных задач. Для согласования с менеджментом используются планы релизов, это позволяет в рамках больших промежутков времени устанавливать объем разработки элементов системы и ее отдельных характеристик. Например, при создании подсистемы поиска в задачу можно включить учет морфологии.

  9. Проблемы некомандного поведения


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



Что нужно изменить в фирме для внедрения agile методологии


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


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

  • Ценности и принципы


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


В этом случае руководство постепенно приучает всех сотрудников компании к необходимости внедрения и высокой эффективности методологии agile. Именно так поступили в Bosch: новые принципы лидерства подготовили все структуры компании к тому, что гибкий подход станет основой их деятельности.

  • Управление архитектурой


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


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


Новые пути общения между agile-командами и традиционными структурами (в том числе HR и финансами) ищет и разработчик игр Riot Games:

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

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


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




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


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


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

  • Талант и мотивация сотрудников


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


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


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

  • Ежегодный цикл планирования и формирования бюджета


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


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

Как сформировать команду для работы по методологии agile


Для успешного формирования команды необходимо:

  • оценить личные качества претендентов,

  • проверить их на совместимость,

  • выявить скрытых лидеров и любителей конфликтов.


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


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


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


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


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


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


Куратором проекта стал коммерческий директор, прошедший предварительное обучение основам методологии agile.


Проблемы не заставили себя ждать.


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


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




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


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


Что мы имеем?

  • Есть наставник.

  • Есть руководитель.

  • Есть команда.


Настал черед определить цели и задачи пилотного проекта.


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


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


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

Как выбрать бизнес-тренера по методологии agile


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


Чаще всего приходится наблюдать следующие ошибки выбора бизнес-тренера:


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


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


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


Оптимальный вариант – найти тренера, который будет:

  • человеком бизнеса,

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


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


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


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


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

Как рассказать что такое Agile на заводе? Топ 5 самых популярных Agile-практик

Если оторваться от Хабра, заглянуть в реальную российскую компанию старше 30 лет и больше чем с тысячью сотрудников и произнести слово Agile, то реакция будет как минимум настороженная. Люди там уже слышали истории похожие на «Как рассказать бабушке» или «Как рассказать дедушке» и посмотрели все выступления Грефа, получили с десяток предложений внедрить гибкость за неделю, кто-то из сотрудников даже поработал год со Scrum, но остается один вопрос:

«Что с этим нам делать то, у нас из программирования только сайт?»

В итоге примерно для 100% компаний Agile смахивает на шарлатанство.

Но вот парадокс — в мире 77% компаний*, использующих Agile в проектах, занимаются совсем не разработкой программного обеспечения.

*Из большого ежегодного опроса компаний от VersionOne

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


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

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

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

Команда в игре «Что? Где? Когда?» существует по принципам Agile. Взаимодействиям отдана ключевая роль. Капитан выполняет роль заказчика продукта (верного ответа), 2-3 эрудита перебирают массивы информации, кто-то следит за временем, есть человек, который анализирует, задает вопросы и побуждает общение, любой может высказаться и привести к результату или все провалить, за пределами игры есть разбор полетов (ретроспектива).

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

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

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

Но. Даже если вы веб-студия и для вас это тысячный сайт, для клиента это первый раз. И его желания останутся неопределенностью до самого конца. Многие студии делают 3-4 варианта главной страницы и закладывают неделю на непредвиденные доработки. У всех, кого я знаю, работа разбита на итерации, после каждого есть демонстрация и обсуждение. Общение с заказчиком важнее подписанного контракта.

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

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

Итого ключевые ценности Agile (манифест):

  • свободное взаимодействие в команде

  • результативность проекта (классный продукт)

  • партнерское общение с клиентом

  • готовность к изменениям

Что такое команды с ролями?

В привычной команде есть две роли: Начальник и Подчиненный, один умный другой дурак. В Agile принципиально важны три: Заказчик продукта, Методист, Участник команды.

В упрощенной форме:

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

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

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

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

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

Со стороны гибкая команда от привычной отличается именно наличием или отсутствием так называемого повествовательного диалога (narrative collaboration).

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

Главный вопрос: «Как управлять ресурсами когда все так гибко?»

Все эти рассказы про ответственные команды и истории появления метода воспринимаются как полная фигня, если нет ответа на вопросы:

«А как точнее управлять ресурсами?», «Как раньше понять, что в проекте ресурсов стало не хватать для окончания?», «Мы всегда ставили и распределяли задачи по исполнителям и могли прогнозировать результат, а что теперь?». Что бы рассказать про Agile, можно раскрыть только этот вопрос.

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

Есть несколько важных принципов и методов, явно направленных именно на прогнозирование ресурсов:

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

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

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

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

Спринт (итерация) — это отрезок времени в несколько недель. У нас чаще всего это 2 недели. Самое важное в спринте — это определение того, какой промежуточный результат должен быть получен. Этим результатом хорошо называть итерацию, например, «Выпуск досок с правами» или «Выпустить сайт на тест». Если работа идет по отрезкам времени, но каждый отрезок не приводит к какому-то конкретному результату, то это уже не итерационный подход.

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

Мы используем третий, но оценки бывают только 1h, 2h, 4h, 8h.

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

5. Burndown chart (график сгорания)

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

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

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

  • самый успешный подход — заложить запас по времени, планировать на 80% ресурсов

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

Топ 5 самых популярных Agile-практик понятных всем

Еще раз подчеркну, Agile на базовом уровне применения — это просто. Нет никаких сверхсложных приемов, которые надо долго изучать. Ниже для примера приведено 5 самых популярных практик (по данным все того же опроса от VersionOne)

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

1. Итерационное планирование — спринты (90% команд используют)

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

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

2. Ежедневные планерки (88% команд используют)

Задача — чтобы каждый день команда подтверждала единое направление движение всех участников.

По классическому описанию каждый в команде раскрывает три вопроса:

Что сделано к этому моменту из спринта?

Что планируется на сегодня?

Какие проблемы возникли или что мешает?

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

Менять время планерки — 6 мес. утром, 6 мес. вечером.

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

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

Обсуждать общие темы и только потом переходить к вопросам.

Не пускать на планерки никого кроме участников команды.

3. Ретроспективы (83% команд используют)

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

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

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

4. Итерационные показы (81% команд используют)

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

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

5. Короткие итерации (71% команд используют)

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

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

Как понять ведется ли проект по Agile-методологии или еще нет?

Диаграмма того, сколько компаний меняют Agile под себя выглядит так:

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

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

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

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

P.S. Опрос: Agile в России 2017

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

Примите участие — пройдите опрос «Agile в России 2017»

10 вопросов, 3 минуты

Результаты обязательно будут опубликованы на Хабрахабр.

кратко о методологиях Agile / Блог компании ИТ Гильдия / Хабр

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

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

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

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


/ Flickr / Sebastian Sikora / CC

Scrum

Scrum — это фреймворк гибкой разработки ПО, который считается методологией «по умолчанию». Для многих является синонимом Agile. По статистике за 2016 год, предоставленной VersionOne, Scrum используют 58% «гибких» компаний. При этом её поддерживают многие SaaS-платформы. Например, решение ServiceNow, частью которого является инструмент Agile Development.

Методология была разработана в конце 80-х — начале 90-х годов. Процесс управления состоит из фиксированных коротких итераций — спринтов (sprints).

Используя методологию Scrum, представитель заказчика плотно работает с командой разработки, расставляя приоритеты в списке требований к продукту (Product Backlog). Этот список состоит из баг-фиксов, функциональных и нефункциональных требований — из всего, что нужно сделать для реализации рабочего приложения.

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

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

За последние десять лет программисты Кен Швабер (Ken Schwaber), Майк Бидл (Mike Beedle) и Джефф Сазерленд (Jeff Sutherland) приложили множество усилий для развития Scrum. Кен Швабер — наиболее активный сторонник фреймворка, и его сайт — хорошее место, чтобы начать свое знакомство с методологией. Он также выпустил книгу.

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

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

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

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

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

Extreme Programming

Особенность Scrum заключается в том, что этот фреймворк уделяет мало внимания практикам разработки. Поэтому некоторые agile-компании (порядка 10%) комбинируют его с экстремальным программированием (XP).

Экстремальное программирование привлекло к себе внимание в конце 90-х. Концепция зародилась в сообществе Smalltalk, а её авторами считаются разработчики Кент Бек (Kent Beck) и Уорд Каннингем (Ward Cunningham), которые хотели сформировать новые практики в разработке ПО, сделанные для людей.

Первым проектом, созданным по методологии Extreme Programming, стала система контроля платежей Chrysler Comprehensive Compensation (C3) в середине девяностых. Сам термин «экстремальное программирование» появился в 1997 году.

Концепция строится на основании двенадцати приёмов:

  1. Разработка через тестирование (Test-driven development)

  2. Игра в планирование (Planning game)

  3. Заказчик всегда рядом (Onsite customer)

  4. Парное программирование (Pair programming)

  5. Непрерывная интеграция (Continuous integration)

  6. Рефакторинг (Design improvement)

  7. Частые небольшие релизы (Small releases)

  8. Простота проектирования (Simple design)

  9. Метафора системы

  10. Коллективное владение кодом (Collective code ownership)

  11. Стандарт оформления кода (Coding standard)

  12. 40-часовая рабочая неделя (Sustainable pace)

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

Однако Extreme Programming делает сильный упор на тестирование, что отличает её от Scrum. Методология гласит, что разработчик не может сказать, что код написан правильно до тех пор, пока не пройдут все модульные тесты. Поэтому часто XP идет рука об руку с техникой разработки Test Driven Development (TDD), когда сперва пишется тест, а затем логика для его прохождения.

Но такая «тестоориентированность» одновременно и недостаток подхода. Чтобы адаптировать XP, нужно инвестировать в создание инфраструктуры автоматизированных тестов и непрерывного развертывания ПО.

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


/ Flickr / U.S. Army / CC

Канбан

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

Однако сегодня многие команды рассматривают иные варианты и обращают внимание на другие методологии. Одной из них стал канбан. CTO ConvertKit Грант Аммонс (Grant Ammons) говорит, что компании сперва адаптируют Scrum, который учит их необходимым дисциплинам для разработки ПО, а затем ищут более удобную альтернативу и обращаются к канбану.

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

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

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

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

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

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

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

P.S. Еще несколько статей из нашего корпоративного блога:

Что такое Agile [5 ключевых вопросов]

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

Разберемся с Agile: Что такое Agile и как использовать в практике бизнеса

Давайте разберемся и определим: что такое Agile? и каким образом  можно внедрить Agile (методы гибкого управления)  в своих компаниях и  как нужно это на самом деле делать?

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

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

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

Содержание статьи [бизнес блог]

Что такое Agile?

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

Рекомендую изучить по Agile

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

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

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

Как компании используют Agile (эджайл) в своей работе

Возможности Agile

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

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

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

Скачать листовку для руководителя: корпоративный тренинг по Agile

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

Что такое Agile Для чего использовать Agile в бизнес-процессах компании

Зачем внедрять Agile методы гибкого управления в компании

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

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

Зачем нужен Agile?

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

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

[bctt tweet=»Agile это не конкретная технология — это набор различных методов и подходов» username=»SavkinKS»]

Проектная команда по внедрению Agile

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

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

[su_note note_color=»#FFFF66″ text_color=»#333333″ radius=»3″ class=»»]
Методы гибкого управления Agile (эджайл) позволяет:

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

[/su_note]

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

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

Мы узнали что-то новое? Скорее всего нет, а с другой стороны ДА!

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

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

Внедрение Agile в больших компаниях

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

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

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

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

Рекомендую ознакомиться: Стоимость внедрения Agile в компании

Конфликты при внедрении Agile

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

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

[su_note note_color=»#FFFF66″ text_color=»#333333″ radius=»3″ class=»»]Если мы игнорируем согласование как факт, то нарушаем бизнес-процессы компании, а следовательно это может привести к довольно серьезным последствиям.[/su_note]

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

Пример внедрения Agile

Рассмотрим простой пример, который я привожу на своем корпоративном тренинге по Agile, когда рассматриваем с руководителями вопрос формирования Agile команд:

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

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

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

[su_note note_color=»#ADFF2F» text_color=»#333333″ radius=»3″ class=»»]Прямой зависимости между Agile и прибылью компании нет, пока нет, но скоро будет![/su_note]

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

Как работает Agile в России

На мой взгляд:

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

[su_note note_color=»#FFFF66″ text_color=»#333333″ radius=»3″ class=»»]Для достижения результата собственник или ТОП менеджмент любых компаний очень часто обращается к своим доверенным лицам или сотрудникам,  для того чтобы найти то или иное интересное решение, а не создают Agile команды, я думаю понятно над чем следует работать.[/su_note]

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

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

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

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

Agile и антикризисное управление

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

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

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

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

Так что как инструмент антикризисного управления Agile вполне подойдет для многих российских компаний.

Agile, делаем выводы

Многие компании, которые стремятся внедрить Agile забывают:

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

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

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

Последние статьи по Agile:

[catlist id=662 numberposts=5]

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

90000 What is Agile Methodology? Tools, Best Practices & More 90001 90002 Agile Methodology is a people-focused, results-focused approach to software development that respects our rapidly changing world. It’s centered around adaptive planning, self-organization, and short delivery times. It’s flexible, fast, and aims for continuous improvements in quality, using tools like 90003 Scrum 90004 and 90003 eXtreme Programming 90004. 90007 90008 How It Works 90009 90002 It works by first admitting that the old «waterfall» method of software development leaves a lot to be desired.The process of «plan, design, build, test, deliver,» works okay for making cars or buildings but not as well for creating software systems. In a business environment where hardware, demand, and competition are all swiftly-changing variables, 90011 agile works by walking the fine line between too much process and not enough 90012. 90007 90008 Agile Methodology Overview 90009 90002 It abandons the risk of spending months or years on a process that ultimately fails because of some small mistake in an early phase.It relies instead on trusting employees and teams to work directly with customers to understand the goals and provide solutions in a 90011 fast and incremental way 90012. 90007 90020 90021 90011 Faster, smaller. 90012 Traditional software development relied on phases like outlining the requirements, planning, design, building, testing, and delivery. Agile methodology, by contrast, looks to deploy the first increment in a couple weeks and the entire piece of software in a couple months. 90024 90021 90011 Communication 90012.Agile teams within the business work together daily at every stage of the project through face-to-face meetings. This collaboration and communication ensure the process stays on track even as conditions change. 90024 90021 90011 Feedback 90012. Rather than waiting until the delivery phase to gauge success, teams leveraging Agile methodology track the success and speed of the development process regularly. Velocity is measured after the delivery of each increment. 90024 90021 90011 Trust 90012.Agile teams and employees are self-organizing. Rather than following a manifesto of rules from management 90003 intended 90004 to produce the desired result, they understand the goals and create their own path to reach them. 90024 90021 90011 Adjust 90012. Participants tune and adjust the process continually, following the KIS or 90011 Keep It Simple 90012 principle. 90024 90045 90002 For training purposes, there’s a comprehensive, downloadable overview here. 90007 90048 90049 90048 90008 Examples of Agile Methodology 90009 90002 The most popular and common examples are Scrum, eXtreme Programming (XP), Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), Adaptive Software Development (ASD), Crystal, and Lean Software Development (LSD).Teams generally pick one or two methods. The most widely used methodologies are Scrum and XP, which dovetail nicely. 90007 90002 90011 Scrum 90012 is a hands-on system consisting of simple interlocking steps and components: 90007 90020 90021 A product owner makes a prioritized wish list known as a product backlog. 90024 90021 The 90003 scrum team 90004 takes one small piece of the top of the wish list called a 90003 sprint backlog 90004 and plans to implement it. 90024 90021 The team completes their sprint backlog task in a 90003 sprint 90004 (a 2-4 week period).They assess progress in a meeting called a 90003 daily scrum. 90004 90024 90021 The 90003 ScrumMaster 90004 keeps the team focused on the goal. 90024 90021 At the sprint’s end, the work is ready to ship or show. The team closes the sprint with a review, then starts a new sprint. 90024 90045 90002 Here’s an example of how Scrum works: Bill meets with a customer to discuss her company’s needs. Those needs are the product backlog. Bill chooses the most important tasks to work on in the next two weeks.His team meets in a daily scrum to target work for the day ahead and address roadblocks. At the end of the sprint, Bill delivers the work, reviews the backlog, and sets the goal for the next sprint. The cycle repeats until the software is complete. 90007 90002 90084 90007 90002 90003 Image via Open-Ware.org 90004 90007 90002 90007 90002 90011 eXtreme Programming. 90012 Often used with scrum, XP is an example of how Agile can heighten customer satisfaction. Rather than deliver everything the customer could ever want far in the future, it gives them what they need now, fast.XP is centered on frequent releases and short development cycles. It uses code review, pair programming, unit testing, and frequent communication with the customer. 90007 90002 Here’s an example of how XP works: Bill builds a list of customer requirements by having the customer tell «user stories» that outline the features. From these, he builds a software release plan. The software will be delivered in iterations, with one delivered every couple weeks. The team works in programmer pairs, using daily meetings to smooth roadblocks.The customer delivers feedback in the form of more user stories. The cycle repeats until the software is delivered. 90007 90002 For more examples, see this article. 90007 90048 90049 90048 90008 Benefits of Agile Methodology 90009 90002 The benefits of Agile are tied directly to its faster, lighter, more engaged mindset. The process, in a nutshell, delivers what the customer wants, when the customer wants it. There’s much less wasted time spent developing in the wrong direction, and the entire system is quicker to respond to changes.For a more comprehensive list of benefits, see this post. 90007 90020 90021 90011 Faster 90012. Speed ​​is one of the biggest benefits of Agile Methodology. A faster software development life cycle means less time between paying and getting paid. That, in turn, means a more profitable business. 90024 90021 90011 Increased customer satisfaction 90012. With Agile, customers do not wait for months or years, only to get exactly what they did not want. Instead, they get iterations of something very close to what they want, very fast.The system adjusts quickly to refine the successful customer solution, adapting as it goes to changes in the overall environment. 90024 90021 90011 Values ​​employees 90012. Employees whose ideas are valued are vastly more productive than those who are ordered to follow a set of rules. The Agile Methodology respects employees by giving them the goal, then trusting them to reach it. Since they’re the ones with their hands on the controls and the ones who see the obstacles that crop up every day, employees are in the best position to respond to challenges and meet the goals at hand.90024 90021 90011 Eliminates rework. 90012 By involving the customer at more than just the phases of requirements and delivery, the project remains on-task and in-tune with customer needs at every step. This means less backtracking and less «out on a limb» time between the time we do the work and the time the customer suggests revisions. 90024 90045 90008 Best Practices 90009 90002 The list of best practices is long and involved, with dozens of tools to pick and choose. We’ve outlined a short list of the main benefits below.For a more comprehensive best practices guide, see this article. 90007 90020 90021 90011 Set priorities 90012. A 90003 product backlog 90004 is a list of prioritized tasks maintained by a 90003 product owner. 90004 90024 90021 90011 Maintain small release cycles. 90012 The product should be released in increments every 2-4 weeks, with stakeholders giving feedback before proceeding. 90024 90021 90011 Use pair programming. 90012 Two programmers work side-by-side at a single computer.This technique actually results in an identical degree of productivity to separate programming but delivers higher quality. 90024 90021 90011 Refactor. 90012 Rework code regularly to achieve the same result with greater efficiency and clarity. 90024 90021 90011 Use test-driven development. 90012 Code the unit test first to keep the project on task throughout. Test-driven development as an Agile best practice also produces greater employee engagement, since it transforms testing from a boring grind to a coding challenge.90024 90045 90008 Agile Methodology Tools 90009 90002 The list below shows some of the best tools on offer. For a complete list, see this post. 90007 90020 90021 90011 ActiveCollab 90012 90011. 90012 An affordable tool for small businesses, ActiveCollab is easy to use. This software development aid requires little training and provides excellent support. 90024 90021 90011 Agilo for Scrum 90012 90011. 90012 Stakeholders get updated automatically on the project’s progress with Agilo for Scrum.Features sprint reports and burn down charts for better data mining. 90024 90021 90011 Atlassian Jira + Agile 90012 90011. 90012 This powerful project management tool facilitates development by incorporating Scrum, Kanban, and customizable workflows. 90024 90021 90011 Pivotal Tracker 90012 90011. 90012 This methodology tool is geared specifically for mobile projects. A little jargon-heavy, it’s user-friendly after a brief orientation period. 90024 90021 90011 Prefix. 90012 This free tool from Stackify provides an instant feedback loop to catch and fix bugs before they can deploy.90024 90021 90011 Retrace 90012. For a more robust solution complete with monitoring, errors, logs, and more, Stackify’s Retrace provides app performance insights from integration to QA to production, at the code level. 90024 90045 90008 Additional Resources 90009 90002 Make use of the non-product style tools and resources for success below, including the original Agile manifesto and a few downloadable templates for implementation. 90007 90020 90021 Agile Manifesto. This is the original document that kicked off the Agile movement.It contains all 12 key tenets of the methodology at large. 90024 90021 Burn Down Charts. These are visual representations of work left vs remaining time. Download an Excel template here from SmartSheet.com. 90024 90021 Agile project plan. This is a tool for tracking the progress of the overall Agile project. This article from Ambysoft outlines the entire project planning process. 90024 90021 Agile product backlog. This helps product owners track and prioritize customer requirements. You can download an Excel template here.90024 90045 90002 Agile is a popular development methodology widely used by development teams who need to ship apps efficiently. But Agile development requires Agile support, so dev leaders must arm their teams with the tools and resources they need to succeed. Check out this post for some valuable tips for making Agile less fragile. Also, check out our great list of scrum boards. 90007 90002 90210 About Stackify 90211 Stackify provides developer teams with unparalleled visibility and insight into application health and behavior, both proactively in a monitoring role as well as reactively in a troubleshooting role, while eliminating the need to login to servers and other resources in order to investigate application problems.90007.90000 What Exactly Is Agile? A Definition of Agile Project Management 90001
90002 90003 «Thinking outside the box» for the 21st century, or the key to success? Let’s get to the bottom of Agile project management. 90004 90005
90006 In 2001 at Utah’s Snowbird ski resort, 17 software developers got together to discuss lightweight software development methods and produced the groundbreaking Agile Manifesto. 90007
90006 The declaration of principles was meant to streamline the software development process by discouraging inefficient practices such as heavy documentation, excessive meetings, and rigid adherence to process.90007
90006 Those developers certainly had vision, but there’s no way they could have known back then what the Agile movement would become. Almost 20 years later, Agile is everywhere. It has become a full-on business buzzword among the ranks of «synergy,» «disruptive,» and the all-time great, «thinking outside the box.» 90007
90006 At businesses around the world, everyone from the executive suite to the mailroom is boasting about who’s more Agile than whom. 90007
90002 Agile is more than just a buzzword 90005
90006 The big difference between Agile and the rest of the project management buzzwords that came before it? Agile is an actual approach to project management with an actual definition.You can not «think outside the box» in any quantifiable way, but you can implement Agile project management at your business if you know what it actually is. 90007
90006 And you should implement Agile project management at your business if you want to be successful. If your business is not using Agile, you’re in the increasing minority, and you’re falling behind as a result. 90007
90006 According to the Project Management Institute, more than 70% of organizations have incorporated an Agile approach, and Agile projects are 28% more successful than traditional projects.90007
90006 We’re going to cut through the clutter to give a clear, concise definition of the term so that you can correct your manager the next time they talk about how Agile they were with their series of afternoon meetings to plan next month’s series of planning meetings. 90007
90006 By understanding what Agile really means, you’ll also be better equipped to help implement Agile practices at your organization, and recognize situations that could be improved with a dash of Agile (like nixing the weekly meeting-planning meeting).90007
90006 We’ll also look at three real-world examples of Agile project management in action. 90007
90006 Take this quick assessment to find out how Agile you are as a project manager, and where you could use some improvement! 90007

90002 What is agile project management? 90005
90006 The first-and perhaps most pure-definition of Agile project management comes from the Agile Manifesto itself, which lists four overarching values. 90007
90034 What are the 4 Agile values? 90035
90036
90037 Individuals and interactions over processes and tools 90038
90037 Working software over comprehensive documentation 90038
90037 Customer collaboration over contract negotiation 90038
90037 Responding to change over following a plan 90038
90045
90046
90047
90048
90049 Agile 90050
90049 Not Agile 90050
90053
90048
90055
90056
90037 Value individuals and interactions 90038
90037 Value working software 90038
90037 Value customer collaboration 90038
90037 Value responding to change 90038
90065
90066
90055
90056
90037 Value processes and tools 90038
90037 Value comprehensive documentation 90038
90037 Value contract negotiation 90038
90037 Value following a plan 90038
90065
90066
90053
90080
90081
90006 But we can distill that somewhat arcane summary to come up with a more concise definition.90007

90084 90085 The definition of Agile project management 90086
90006 Agile project management is an iterative development methodology that values ​​human communication and feedback, adapting to change, and producing working results. 90007

90006 Now let’s break that down. 90007
90056
90037 Agile is 90093 iterative 90094, meaning that it is done in pieces (sprints), with each sprint building and improving off the lessons from the previous sprint. This is where that term Scrum comes into play.What is Scrum? Scrum methodology is a workflow framework made up of sprints and reviews used to promote Agile project management. 90038
90037 Unlike Scrum, which can be distilled to a step-by-step process, Agile is an 90093 approach and a mindset. 90094 It’s not a textbook, or a list of instructions, or a certification. In fact, trying to turn Agile into a black-and-white template goes against everything that Agile is. It would be like trying to give someone a step-by-step plan on how to be «cool,» or play jazz.However, there is project management software that is designed specifically to promote agility. 90038
90037 Agile project management is all about 90093 efficient communication 90094 over documentation, convoluted email chains, or excessive meetings. According to the 12 principles behind the Agile Manifesto: «The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.» If you can communicate something with a 10-second conversation instead of an email, you should.90038
90037 Agile is about 90093 producing tangible, working results 90094 after each iteration. According to the 12 principles, «Working software is the primary measure of progress.» To compare Agile to the editorial process-you deliver a rough draft, then revise based on your editor’s suggestions. You’re not delivering the entire piece all at once on the day it goes to press. 90038
90065

90002 What are the 12 principles of Agile? 90005

90111
90006 The 12 principles of Agile, according to the Agile Alliance, are as follows: 90007
90036
90037 Satisfy the customer through early and continuous delivery of valuable software.90038
90037 Welcome changing requirements. 90038
90037 Deliver working software frequently. 90038
90037 Work together daily throughout the project. 90038
90037 Build projects around motivated individuals who are supported and trusted to get the job done. 90038
90037 Use face-to-face conversation whenever possible. 90038
90037 Working software is the primary measure of progress. 90038
90037 Maintain a constant pace indefinitely. 90038
90037 Give constant attention to technical excellence and good design.90038
90037 Simplicity-the art of maximizing the amount of work not done-is essential. 90038
90037 The best architectures, requirements, and designs emerge from self-organizing teams. 90038
90037 Reflect on how to become more effective, then tune and adjust accordingly at regular intervals. 90038
90045

90002 Real-life examples of Agile project management 90005
90006 Entire books have been written on Agile project management, and we could dissect it from 100 different angles and through the scope of dozens of different industries.But this article is about coming up with an easy-to-understand explanation of Agile. 90007
90006 So let’s look at a few examples of Agile in the real world. 90007
90034 1. The build-your-own meal 90035
90006 Everyone is familiar with the build-your-own-meal trend in fast, casual dining. At restaurants such as Chipotle or Subway, an employee puts your meal together as you give feedback. 90007
90006 More cheese? Less cheese? Different bread? Guacamole? No guacamole? No problem. 90007
90006 Every step of the way, your food project manager checks in with you to make sure your food project is still on track.The end result is a delicious meal that was improved during each step thanks to constant face-to-face collaboration. 90007
90034 2. The Apple Genius Bar 90035
90006 Looking past the pretentiousness of the name, the Apple Genius Bar is a great, real-world example of Agile project management in action. 90007
90006 When you come in with your busted iPhone or iPad, you do not have to fill out a bunch of forms or wait in a series of lines (it’s more like a waiting gathering). It’s a world apart from your last experience at the DMV.90007
90006 What makes the Genius Bar an Agile process is the focus on communication. The associate you deal with asks you questions and takes notes. In other words: «individuals and interactions over processes and tools.» 90007
90006 You may be saying, «But Apple uses processes and tools, like the iPad they take notes on.» 90007
90006 Yes, but the conversation between humans comes first. 90007
90034 3. Baseball 90035
90006 You may think that this is a stretch but stick with me here. 90007
90006 A baseball manager has to be an Agile project manager to succeed.Every season is a major project made up of 162 games plus playoffs, and each game is an iteration of that project. 90007
90006 Imagine if a baseball manager put the same players in the same positions, batting in the same order for all 162 games despite injuries, poor performance, or bad match-ups. That manager would probably not be very successful (even Lou Piniella with the 2001 Seattle Mariners needed to make adjustments here and there). 90007
90006 In fact, Agile is all over baseball. Infield Scrum meetings at the pitcher’s mound, phone calls to the bullpen (90003 not 90004 emails), a concrete result (win or loss) at the end of every iteration (game).90007
90006 The next time you watch a baseball game, think about how your small-business team could operate more like a baseball team. We advise skipping the chewing tobacco, though. 90007
90002 How Agile is your team? 90005
90006 If you just remember that Agile project management is about human-to-human communication, adapting to changing conditions, and producing working results, you’ll be on the right track. 90007
90006 But Agile project management is, by definition, ever evolving and changing.Ask 10 different project managers to define Agile and you’ll probably get 10 distinct answers. 90007
90006 I’d love to hear how you would define Agile. Let me know in the comments, or hit me up on Twitter @AndrewJosConrad. 90007
90006 You want more on Agile? We’ve got you covered and then some. Visit our project management blog for the latest articles on Agile project management. 90007

.90000 Agile Methodology Basics 90001 90002 The benefits of Agile project management are many, particularly for the following organizations and project types: 90003 90004 90005 Any project that evolves over time or does not have clear scope and requirements at the beginning. 90006 90005 Organizations that work in a fast-changing environment, such as technology. 90006 90005 Organizations that need to work closely with their customers and other external parties throughout the life of the project.90006 90005 Companies that emphasize process and product improvement and are constantly looking to innovate. 90006 90005 Projects that have a lot of interdependent tasks, where the team needs to work closely together and frequently communicate to ensure success. 90006 90005 Companies that need to create a prototype before building the final project outcome. 90006 90005 Projects that require rapid feedback from stakeholders about each product iteration before moving on to the next version or draft.90006 90019 90020 Here are the 5 largest benefits of adopting an Agile method: 90021 90020 Continuous customer contact 90021 90002 Traditional project management methods generally only had the project team in touch with the customer at the beginning and end of the project. Which meant that if customer requirements or expectations were not properly captured in the beginning, or changed over time, the project team had no idea until it was too late. With Agile, there’s ongoing contact throughout the entire process and iterative deliveries to ensure your team is on track, so the end product will be exactly what the customer wants.90003 90020 The ability to adapt 90021 90002 What if your customer told you halfway through a project that they needed a scope change? Using a traditional approach to project management, this either could not be accommodated or likely involved significant increases to both the project cost and schedule. With Agile, changes can be incorporated with minimal effort, no matter how far along in the project your team is, as it can easily be added to the next iteration. 90029 90003 90020 Faster delivery 90021 90002 Agile incorporates a continuous development approach which ensures that your team is constantly delivering workable products.This means that instead of waiting for 6 to 12 months or longer for an end product, your client is getting a working version of the product at much shorter intervals, typically every 2 to 4 weeks. 90003 90020 Lower project risk 90021 90002 Since your team is developing versions of the product regularly and getting customer feedback early on, the risk of a project failing is minimized. By breaking a large project into iterations, your risk is also reduced to the failure of an iteration or draft only.You’re more likely to find small problems early, that can be addressed easily, rather than discovering a large issue only at the time of final testing before the end delivery. This means less time and money will have been invested by the time a problem is discovered or the project needs to be canceled. 90003 90020 Ongoing innovation 90021 90002 Agile supports collaboration and continuous improvement, both of which can lead to innovation and the development of new products and features. By co-locating teams and having daily meetings, brainstorming and idea creation is supported.Agile supports an «idea meritocracy» where the best idea wins out, no matter who it comes from. The project team, other stakeholders, and the customer are able to figure out functionality and features together as a team. 90003.90000 Guide for Software Development & Testing 90001 90002 90003 90004 Home 90005 90004 90007 Testing 90008 90009 90004 90003 90004 Back 90005 90004 Agile Testing 90005 90004 BugZilla 90005 90004 Cucumber 90005 90004 Database Testing 90005 90004 ETL Testing 90005 90004 Jmeter 90005 90004 JIRA 90005 90028 90003 90004 Back 90005 90004 JUnit 90005 90004 LoadRunner 90005 90004 Manual Testing 90005 90004 Mobile Testing 90005 90004 Mantis 90005 90004 Postman 90005 90004 QTP 90005 90028 90003 90004 Back 90005 90004 Quality Center (ALM) 90005 90004 RPA 90005 90004 SAP Testing 90005 90004 Selenium 90005 90004 SoapUI 90005 90004 Test Management 90005 90004 TestLink 90005 90028 90005 90028 90005 90004 90007 SAP 90008 90071 90004 90003 90004 Back 90005 90004 ABAP 90005 90004 APO 90005 90004 Beginner 90005 90004 Basis 90005 90004 BODS 90005 90004 BI 90005 90004 BPC 90005 90004 CO 90005 90028 90003 90004 Back 90005 90004 CRM 90005 90004 Crystal Reports 90005 90004 FICO 90005 90004 HANA 90005 90004 HR 90005 90004 MM 90005 90004 QM 90005 90004 Payroll 90005 90028 90003 90004 Back 90005 90004 PI / PO 90005 90004 PP 90005 90004 SD 90005 90004 SAPUI5 90005 90004 Security 90005 90004 Solution Manager 90005 90004 Successfactors 90005 90004 SAP Tutorials 90005 90028 90005 90028 90005 90004 90007 Web 90008 90009 90004 90003 90004 Back 90005 90004 Apache 90005 90004 Android 90005 90004 AngularJS 90005 90004 ASP.Net 90005 90004 C 90005 90004 C # 90005 90004 C ++ 90005 90004 CodeIgniter 90005 90004 DBMS 90005 90028 90003 90004 Back 90005 90004 Java 90005 90004 JavaScript 90005 90004 JSP 90005 90004 Kotlin 90005 90004 Linux 90005 90004 MariaDB 90005 90004 MS Access 90005 90004 MYSQL 90005 90004 Node. js 90005 90028 90003 90004 Back 90005 90004 Perl 90005 90004 PHP 90005 90004 PL / SQL 90005 90004 PostgreSQL 90005 90004 Python 90005 90004 ReactJS 90005 90004 Ruby & Rails 90005 90004 Scala 90005 90004 SQL 90005 90028 90003 90004 Back 90005 90004 SQL Server 90005 90004 SQLite 90005 90004 UML 90005 90004 VB.Net 90005 90004 VBScript 90005 90004 Web Services 90005 90004 WPF 90005 90028 90005 90028 90005 90004 90007 Must Learn! 90008 90231 90004 90003 90004 Back 90005 90004 Accounting 90005 90004 Algorithms 90005 90004 Blockchain 90005 90004 Business Analyst 90005 90004 Build Website 90005 90004 CCNA 90005 90004 Cloud Computing 90005 90004 COBOL 90005 90004 Compiler Design 90005 90004 Embedded Systems 90005 90028 90003 90004 Back 90005 90004 Ethical Hacking 90005 90004 Excel Tutorials 90005 90004 Go Programming 90005 90004 IoT 90005 90004 ITIL 90005 90004 Jenkins 90005 90004 MIS 90005 90004 Networking 90005 90004 Operating System 90005 90004 Prep 90005 90028 90003 90004 Back 90005 90004 PMP 90005 90004 Photoshop 90005 90004 Project Management 90005 90004 Reviews 90005 90004 Salesforce 90005 90004 SEO 90005 90004 Software Engineering 90005 90004 VBA 90005 90028 90005 90028 90005 90004 90007 Big Data 90008 90307 90004 90003 90004 Back 90005 90004 AWS 90005 90004 BigData 90005 90004 Cassandra 90005 90004 Cognos 90005 90004 90005 90028 90005 90028 90005 90028.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *