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

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

Agile подчеркивает гибкость, адаптивность, скорость и другие концепции.

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

12 принципов AgileManifesto[1]:

1. Рабочий, конкурентоспособный продукт, удовлетворяющий клиента – лучший показатель прогресса и результатов
2. Быстрая и непрерывная поставка продукта, удовлетворяющего клиента
3. Адаптивность продукта к новым требованиям, которые могут повысить его ценность и конкурентоспособность (возможность внесения изменений на всех этапах разработки)
4. Простота и ясность технических решений, документации, процессов и инструментов, чтобы не создавать лишней работы
5. Частое предоставление рабочего продукта (раз в месяц/неделю)

А что, если не Waterfall?

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

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

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

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

Rational Unified Process (RUP) – это наиболее известная методология, использующая итеративную модель разработки. Она была создана и введена в использование в 1990-х годах компанией Rational Software.

R UP относится к набору инструментов для управления процессами, а также к методологии разработки программного обеспечения. Важно отметить, что методология RUP (2) описывает некоторые общие процессы разработки программного обеспечения с использованием конкретных процессов в контексте данной темы. В каком смысле она является жесткой?

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

1. Циклический подход к производству программного обеспечения. Жизненный цикл проекта RUP разделен на 4 фазы и 9 рабочих процессов.
2. Итеративный процесс разработки. RUP-проект состоит из последовательности итераций с рекомендуемой продолжительностью 2-6 недель.
3. Разработка обязательных требований. RUP использует прецеденты или примеры использования для описания требований. Каждый вариант использования представляет собой описание сценария взаимодействия пользователя с системой, который полностью выполняет конкретную задачу пользователя.
4. Постепенный подход, который фокусируется на увеличении функциональности продукта. Основной единицей планирования итераций является сценарий использования, который позволяет вносить необходимые изменения в требования, проектные решения и реализацию в ходе проекта.

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

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

Кратко о том, что входит в agile сегодня

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

Спринты, которые по продолжительности равны коротким итерациям, – вот как работает Scrum. Команда состоит из разработчиков, владельца продукта (который отвечает за успех) и скрам-мастера, и всего есть 10 задач. Что и как должно быть сделано, решает команда.

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

Канбан – это набор руководств и процедур для повышения качества обслуживания.

Scrum и Kanban сильно отличаются друг от друга.

• Имеет более широкий охват (не только новые продукты, но и поддержка, операции);
• В отличие от Scrum, внедряется постепенно (без одномоментных изменений текущих процессов) и более легко (например, без изменения структуры организации);
• Направлен не только на ускорение, но и на стандартизацию процессов;
• Имеет очень отличные от Scrum метрики, которые не требуют оценки трудоемкости задач (например, время прохождения задачи через систему);
• Отличается отсутствием акцента на самоорганизации команды и отсутствием прямой связи практики Kanban с ценностями agile (у Kanban есть свои ценности, многие из которых вполне соответствуют ценностям agile, например, клиентоориентированность, сотрудничество и использование системы Kanban);

Более подробную информацию о различиях между Kanban и Scrum см. в этой статье.

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

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

По скорости вывода новых продуктов на рынок крупные организации часто не дотягивают до стартапов. LeSS (Large-scrum Security) и SAFe (Scaled Agile Framework). Эта стратегия является одной из самых распространенных в России.

На одном экране можно увидеть отличительные характеристики каждого подхода Agile (а также Business Agility), который очень популярен в России.

Разберем основные идеи Agile Manifesto

Основные идеи

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

Начнем с ложки дегтя. Лично для меня все пункты спорны. Пойдем по порядку:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мифы и реальность про Waterfall

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

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

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

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

Давайте окунемся в среду вычислительных центров (ВЦ) той эпохи. Напомню, что в те ранние времена воплотить идею разработчика в работающий компьютер было непросто. Она проходила через “бармалеи”, или забытые устройства подготовки данных.

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

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

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

Определения Гибких методологий

Аджайл существует уже некоторое время, поэтому давайте попробуем оценить определения и точки зрения, которые наиболее популярны в сети. Обращаясь к главному артефакту – Манифесту Agile Software Development Manifesto, – давайте сделаем шаг назад.

Термин Agile был первым результатом в поисковой системе:

Agile-методология разработки программного обеспечения (aggile-методы) – это совокупность подходов к разработке программного обеспечения, использующих итеративную работу на основе методов анализа данных в реальном времени или искусственного интеллекта; создание “живого” программного обеспечения без необходимости установки дополнительных компонентов системы управления системой пользователя (от фундаментальных настроек до системных блоков Windows XP/XML + VPS по умолчанию).

Из данного определения можно выделить следующие важные моменты:

1. Использование итеративного подхода. Здесь нет ничего нового, я лично не слышал о методологии разработки программного обеспечения, которая отрицает этот принцип;
2. Формирование требований происходит шаг за шагом, в процессе разработки продукта. Это, пожалуй, главное отличие от многих других методологий. В некоторых отношениях это является преимуществом, в других – имеет фундаментальные ограничения. О том и другом мы поговорим позже;
3. Используйте тесное и постоянное сотрудничество всех членов команды, включая заказчика. Большинство других методологий, конечно, уделяют внимание взаимодействию команды, в том числе с клиентами, но позиционирование этих взаимодействий как дополнительного ресурса проекта, дающего явное преимущество, более уникально;
4. Самоорганизация команды. Каждая итерация должна заканчиваться подведением итогов (ретроспективой) и внесением конструктивных изменений в процесс, что способствует непрерывному развитию команды. Эти методы могут быть заимствованы из более ранних методов. Например, RUP делает это так.

Это описание многому научило нас в общем мире. Теперь переходим к разъяснениям:

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

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

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

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

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

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

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

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

Хорошо, что эти недостатки не держались в секрете, потому что сделать это было бы сложно по целому ряду причин. Ограниченность во времени, несогласованность действий подчиненных команд, находящихся в разных вертикалях управления, и боязнь принять на себя ответственность. Поскольку во все это было вовлечено высшее руководство компании (АНО “ИТ-Менеджмент”, IT), а приглашенный эксперт был действительно высококлассным техническим специалистом – разработчиком программного обеспечения ERP Publishing Incorpion Group – вся эта деятельность была поддержана.

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

Но поскольку мы собрались вместе, чтобы объективно изучить феномен Agile и его природу, продолжим наше исследование. Начнем с главного документа – Манифеста Agile:

Преимущества, предоставляемые использованием Agile

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

Кроме того, руководители групп и менеджеры проектов могут быстрее понять потребности клиентов.

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

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

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

Необходимость документировать техническое решение (хотя бы постфактум) – единственный момент, который я хочу подчеркнуть. В Sputnik мне сообщили, что они намерены расширить или доработать продукт, наняв новую команду.

Как эффективно использовать Agile в больших интеграционных проектах

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

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

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

В данном разделе важно упомянуть несколько Agile-методик.

Гибкий унифицированный процесс (AUP, англ. Agile Unified Process) — упрощенная версия унифицированного процесса Unified Process (UP), разработанная Скоттом Эмблером. Данная методология разработки программного обеспечения соединяет в себе элементы гибких методологий и унифицированного процесса. В частности, AUP предполагает разработку через тестирование (TDD), применение гибкого моделирования (англ. Agile modeling) и рефакторинга баз данных, гибкое управление изменениями.

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

Как не надо использовать Agile

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

1. Лидером моей анти-квалификации является ситуация, когда Agile, а точнее некоторые из его принципов, соблазняются использовать не для достижения каких-то конкретных целей, которые приносят результат, а просто #Because. Поскольку это тренд, он у всех на устах. Например, кто-то поделился положительными отзывами, немного эфемерными и даже самонадеянными, но сарафанное радио сработало, появился антураж. И теперь те, кто назвал себя учениками Агилы, испытывают чувство общения с другими – принадлежность к элитному клубу. Этому способствует кажущаяся простота методологии и нечеткие контуры ее границ. Реализация в соответствии с этим принципом нерефлексивна и формальна. Люди реализуют принципы, призванные уменьшить формализм, формально и беспринципно. Например, вот совсем недавний случай. Одна компания запретила руководителям команд посещать ретроспективы. Вот в чем фокус. Неожиданно. Моя первая мысль: ну, может быть, они правы, чтобы, например, не было давления на авторитет команды при обсуждении проблем и так далее. Но руководители команд обижены, они озадачены и хотят понять. Я пытался переубедить их, что они могли бы быть такими-то и такими-то лучше, и, прежде всего, что вы – результат списка желаний, со списком того, что нужно изменить, что улучшить и т.д. И здесь раскрывается страшная тайна. Никаких результатов или предложений по улучшению процесса эти встречи не приносят. Итак, ИТ-специалисты, в чем смысл всей этой ретроспекции, просто чтобы поздравить друг друга и укрепить командный дух? Если вы говорите А, говорите и Б. Ведь главная цель этого методологического процесса: “Команда должна систематически анализировать возможные пути повышения эффективности работы и соответствующим образом адаптировать свой стиль работы”.
2. Вторая ситуация в моем рейтинге – это когда команды решают не уделять должного внимания подготовке требований в проектах со сложными поведенческими или логическими алгоритмами. То есть, когда пользовательская история является лишь небольшой частью айсберга проблемы, а основная часть не видна и требует детального и тщательного анализа и проектирования для реализации. Что происходит в этом случае? Перед началом работ ни заказчик, ни разработчики не понимают, даже приблизительно, какой объем работы им предстоит выполнить. И результат: клиент будет платить, платить и платить, и каждый раз будет объяснять, что все было очень сложно и что теперь конца и завершения работы даже не видно. И было бы обидно сдаться, постепенно и сурово осознавая, что этот “золотой” продукт никогда не принесет плодов. Либо разработчики, нанятые для выполнения работы за определенную сумму/время, будут за свой счет (бесплатно) доделывать и переделывать продукт, пока у клиента не иссякнет фантазия, либо не сжалится над жертвами гибкого подхода.
3. Третье почетное место занимает ситуация, когда в рамках большого межфункционального проекта (или, возможно, даже интеграционного проекта) команда решает сэкономить на разработке архитектуры решения и начинает реализовывать отдельные пользовательские истории короткими итерациями. Вполне вероятно, что через 3-5 итераций при попытке создать новую функцию окажется, что всю предыдущую функциональность нужно создавать заново, потому что не были учтены основы, на которых должна была базироваться эта функция. Еще хуже, если после десятой итерации выяснится, что выбранная технология не отвечает всем потребностям заказчика, и вам придется начинать с нуля. Возможно, сменив команду.
4. Ситуация, когда резкий и невероятно гибкий стартап врывается в широкий сегмент вялого рынка, не попала в тройку лидеров. Стартап, по сути, является стартапом, потому что у него нет фундамента, нет связей и, в то же время, нет стабильности и устойчивости. Короче говоря, документации почти нет, команда не скоординирована и часто меняется. Рынок буквально разрывает команду на части, требуя все новых и новых решений в безопасной области, а все последующие проекты просто разваливаются на глазах. Чаще всего это происходит потому, что команда не понимает процессов промышленного производства программного обеспечения, организации доставки продукта и поддержки.

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

Agile – это скорее система ценностей, чем методология разработки.

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

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

Понимание человеком ценностей Agile в данном контексте называется “Agile Mindset” (образ мышления).

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

Неудивительно, что эти два термина используются вместе, поскольку в настоящее время для внедрения Agile-мышления используется структура Scrum.

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

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

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

Гибкость против жесткости: agilevswaterfall

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

Модель водопада (каскада) PM, которая считалась отраслевой нормой.

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

Модель cynefin.

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

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

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

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

В модель включены четыре разных типа систем с разной степенью неопределенности:

1. Простой был заказан

2. Заказанный комплекс

3. Комплекс

4. Хаотичный

Простые упорядоченные.

В данном случае цель, результат и ресурсы команды очевидны.

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

Заказано комплекс.

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

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

Методы управления: PMBok, Prince2, PMI

Сложные системы.

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

Пример: начало круга

Методы: scrum, другие методы.

Хаотические системы.

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

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

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

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

Только 50% от общего числа людей, занимающихся трансформацией, будет отдано ИТ-индустрией в России в 2022 году, поскольку она теряет монополию на Agile.

Agile больше не относится исключительно к разработке ПО.

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

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

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

Об областях, в которых Agile наиболее применим, и основных проблемах, возникающих при использовании системы.

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

Резюме. место agile среди родственных управленческих подходов

Agile – это не методология, и Scrum даже не предлагает Agile как категорию для командных встреч.

.

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

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

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

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

1. Сократить время выхода на рынок / время доставки товара клиенту;
2. Ускорить принятие решений на уровне команды и за ее пределами.

Хотя его иногда называют Agile, термин Enterprise Agility наиболее подходит для ускорения на уровне программ и портфелей проектов (в больших организациях).

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

Agile охватывает, пожалуй, все пять областей “Гибкости процесса”.

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