что такое манифест agile

Agile-манифест разработки программного обеспечения

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

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

То есть, не отрицая важности того, что справа,
мы всё-таки больше ценим то, что слева.

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

дизайн сайта и оформление © 2001, Ward Cunningham
Перевод выполнили: Алексей Солцнев, Сергей Мовчан, Сергей Евтушенко,
Андрей Мудрый, Тим Евграшин, Роман Кононов, Лина Шишкина, Антон Марюхненко и Алек Козлов,
при поддерже сообщества Agile Ukraine

Источник

Что такое Agile и подойдет ли он вашей компании

Что такое Agile

Agile, или Agile software development — гибкий подход к разработке программного обеспечения (ПО), который часто применяют в небольших командах.

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

Термин Agile употребляют в двух основных значениях:

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

Agile возник в противовес устаревшим подходам и излишней бюрократии в сфере ИТ. Резиденты Кремниевой долины (и не только) поняли, что невозможно создавать инновационные продукты в консервативной среде. Поэтому в феврале 2001 года в штате Юта (США) 17 разработчиков из разных стран мира создали свой манифест, в котором объединили самые передовые подходы и принципы.

«Манифест Agile» и основные принципы

Agile-манифест базируется на четырех главных ценностях:

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

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

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

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

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

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

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

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

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

Agile не исчерпывается четырьмя ценностями [1]. В манифесте есть также 12 принципов, которые уточняют и дополняют их. Их можно свести к следующему:

Agile, таким образом, — это система ценностей или даже философия ведения бизнеса. Она помогает сосредоточиться на главном, избавиться от ненужных формальностей и создавать рабочий продукт быстрее и эффективнее. Чтобы воплотить эти ценности на практике, используют конкретные методы. Согласно исследованию Agile в России [2], самые популярные из них — Scrum и Kanban.

Что такое Scrum и Kanban

Scrum, или «подход структуры» — метод на основе Agile, при котором работа над проектами разбивается на спринты — короткие, одинаковые по времени итерации. Команда тоже небольшая — до десяти человек. В нее входят разработчики, product owner (владелец продукта) и scrum-мастер. Product owner — куратор группы, который следит за тем, чтобы конечный продукт отвечал его целям и задачам. Scrum-мастер — человек, который отвечает за правильное применение scrum-метода: организует встречи и обмен сообщениями между всеми участниками. В процессе работы все участники ежедневно обсуждают каждое решение, планы и приоритеты, а также распределяют задачи.

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

В отличие от scrum, kanban:

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

Пример доски Trello, созданной по принципам agile.

Если вы только подступаетесь к философии Agile и хотите попробовать отдельные элементы, проще начать с kanban. Небольшим стартапам и командам, которые только планируют запуск проекта, подойдет scrum.

В каких компаниях используют Agile

Когда Agile только появился, его использовали, в основном, разработчики ПО, игр и интерфейсов. Среди них — Google, Netflix, Microsoft, Spotify, Ericsson, Dell, Adobe, Accenture, WordPress, Riot Games, CH Robinson, Magna International, Scrum Alliance, Intronis.

Теперь же сфера применения расширилась: Agile используют, например, Saab для производства новых истребителей, General Electric и John Deere — ведущий американский производитель сельхозтехники.

Существует ли Agile в России

В Россию Agile пришел на несколько лет позже, но уже сегодня его активно используют в ИТ-секторе, ретейле, банках, онлайн-сервисах, промышленных предприятиях. Среди них — ПО-разработчик First Line Software, гипермаркет электроники «М.Видео», служба доставки Dostаевский, онлайн-кинотеатр ivi, бренд одежды 12 Storeez, металлургический концерн НМЛК.

ScrumTrek проводит ежегодное исследование Agile в России. В прошлом году в нем приняло участие более 1 тыс. компаний из 80 городов. Вот главные цифры за 2020 год [3]:

Нужен ли вашей команде Agile

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

Другими словами, Agile идеален для инновационных стартапов, но мало подходит корпорациям с отлаженными процессами и сложной структурой. Для таких компаний лучше работают методы с отдельными элементами Agile, которые проще масштабировать — SAFe (Scaled Agile Framework) и LeSS (Large-Scale Scrum).

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

Чтобы протестировать новую идею, не проходя все этапы разработки, подойдут Customer Development, Design Thinking и другие продуктовые методики.

Наконец, есть более широкий подход, который включает в себя agile-методики — Business Agility («гибкость в бизнесе»). Он распространился позже — два-три года назад — и включает не только ускорение разработки и выпуска продукта, но и быструю реакцию на внешние изменения, гибкое целеполагание и распределение ресурсов.

Источник

Agile — манифест разработки программного обеспечения. Agile/Scrum/Kanban: разбираемся вместе

Манифест гибкой разработки программного обеспечения ( Agile Manifesto ) — основной документ, содержащий описание ценностей и принципов гибкой разработки программного обеспечения, разработанный в феврале 2001 года на встрече 17 независимых практиков нескольких методик программирования, именующих себя «Agile Alliance».

Текст манифеста доступен на более чем 50 языках (и на русском), и включает в себя 4 ценности, 12 принципов.

Ценности Agile Manifesto

Таким образом, не отрицая важности того, что справа, всё-таки больше ценится то, что слева.

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

Основополагающие принципы Agile-манифеста

Мы следуем таким принципам:

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

А теперь давайте пройдемся по заблуждениям относительно Agile Manifesto

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

Принцип № 1: «Наивысшим приоритетом для нас является удовлетворение потребностей заказчика благодаря регулярной и ранней поставке ценного программного обеспечения».

Сосредоточивая внимание на «удовлетворении потребностей заказчика», адепты Agile совершенно забывают о части «благодаря». Они считают, что их истинная цель — счастливый заказчик, а «continuous delivery» — это что-то, очевидно, полезное, но не принципиальное. Однако всё совсем наоборот: заказчик будет удовлетворен, если ПО идеально создается и доставляется. Если заказчик не удовлетворен, мы ищем другого — вот истинный дух, которого должна придерживаться команда разработки ПО. Я полагаю, что Манифест имеет в виду именно это. Мы гарантируем, что наш процесс «ранний и непрерывный», и это приведет к удовлетворенности заказчика. Мы сосредоточиваемся на улучшении своего процесса, а не на удовлетворении заказчика. Удовлетворение — это последствие, а не основная цель.

Принцип № 2: «Изменение требований приветствуется даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества».

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

Принцип № 3: «Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев».

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

Принцип № 4: «На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе».

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

Принцип № 5: «Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им».

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

Принцип № 6: «Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды».

«Непосредственное общение» не значит «сидеть в одном офисе». Манифест ничего не говорит о совместно размещенных или распределенных командах. Очевидно, что в современных программных проектах виртуальные коммуникации (c помощью видеозвонков) гораздо эффективнее, чем совместная работа в одной стране, одном городе, одном офисе и одной комнате. Поэтому большинство адептов Agile всё ещё продвигает такой стиль разработки, когда все находятся в одном месте, в качестве доказательства используя Манифест. Это ошибка; «непосредственное общение» означает нечто совершенно иное, чем 15 лет назад, когда был написан Манифест.

Принцип № 7: «Работающий продукт — основной показатель прогресса».

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

Принцип № 8: «Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки».

Это не значит, что мы должны бесконечно прожигать деньги заказчика. Да, мы должны вести разработку с определенной скоростью, но всегда должны помнить, чьи деньги тратим: деньги заказчика. Манифест ничего не говорит о стоимости разработки, и это, видимо, из-за того, что его писали те, кто делает деньги (программисты), а не те, кто тратих их (заказчики). Поэтому мы должны помнить, что любой проект — это прежде всего машина для сжигания денег. Вот почему команда всегда должна измерять свою «скорость прожигания» и следить за тем, чтобы она соответствовала количеству business value, которое команда поставляет. Просто быть счастливой командой — это не то, что предлагает Манифест, но именно так многие понимают этот принцип.

Принцип № 9: «Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта».

Принцип № 10: «Простота — искусство минимизации лишней работы — крайне необходима».

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

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

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

Принцип № 12: «Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы».

Это замечательный принцип, который воплощается в так называемых «ретроспективах». Они отлично работают, пока решения делают команду лучше. К сожалению, в большинстве случаев программисты в Agile-командах пытаются выжить, а не сделать команду более эффективной. Хотя принцип гласит, что команда должна стать эффективнее, эти «ретроспективы» помогают программистам стать эффективнее (читай: в большей безопасности) в команде. Это естественно для людей, но приводит к общей деградации команды. Общеизвестно, что лучшая команда — та, которая способна быстро и неумолимо отторгать плохие элементы. Ваша команда делает это эффективно? Помогают ли в этом «ретроспективы». Сомневаюсь. Поэтому я считаю, что здесь Манифест имеет в виду не собрания Он имеет в виду, что у команды должен быть эффективный механизм саморегуляции и самосовершенствования. Кроме того, ретроспективные встречи просто не могут быть таким механизмом, потому что они мешают команде принимать трудные дисциплинарные решения.

Вячеслав Цырульник писал в своём блоге на Medium колонку о том, что такое манифест Agile, зачем он нужен компаниям и как лучше трансформировать бизнес. Очень правильные замечания по теме.

Agile — прилагательное

В переводе с английского языка, Agile («эджайл») — гибкий. Поэтому все эти фразы, которые я встречал за последнее время в интернете:

можно перевести, как:

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

Так, а что же там за манифест

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

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

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

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

В оригинале книга называется «Scrum — the art of doing twice the work in half the time», что практический любой бесплатный электронный переводчик переведёт как «Scrum — искусство делать вдвое больше работы в два раза быстрее». Ни слова о проекте. Scrum вообще не про проекты. Увы и ах.

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

— из Agile-манифеста

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

Кстати, позвольте придерусь к первой ценности в русскоязычном манифесте. В оригинале на месте слова «важнее» стоит слово “over», которое дословно переводится как «над». То есть дословный перевод — «Люди и взаимодействие над процессами и инструментами».

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

Agile — про создание программных продуктов?!

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

Такой план невозможно составить, например, если у вас:

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

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

Всё, уже можно про Scrum?

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

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

Трансформация компании

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

В каждой компании, которая достаточно давно на рынке, есть определенная сложившаяся культура — свои ритуалы, понятия, формальные и неформальные правила.

Фундаментально, существует два пути изменить что-либо:

Scrum

Как сформировать Scrum команду? Нам нужно помочь людям стать такими:

Простой пример — компания не отменила персональные KPI, и запускает Scrum. Но в Scrum ответственность командная, вот и «приехали». На практике, успешные истории транфсормации компаний с помощью Scrum:

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

Kanban

С тем как сломать и построить заново всё понятно — искать квалифицированного Scrum-мастера (или своего воспитывать), выявлять инициативных желающих, формировать команды и вперёд на ежедневные тренировки.

Но можно не ломать, а менять последовательно. В интернете часто упоминается фраза «Kanban-доска», увы, к реальному «Канбану» она имеет крайне отдаленное отношение.

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

Kanban — про правильные процессы. Правильные — с точки зрения достижения целей вашей организации. Рельсы, на которых ваша организации будет уверенно двигаться вперёд. Так что не спешите бежать сломя голову в Scrum, как минимум познакомьтесь с плавными методами трансформации.

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

Оказывается, Agile — сложно?

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

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

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

Маркетинг, продажи и Agile

А теперь, внимание. Моя любимая история. «Привет, мы теперь используем Scrum/Kanban/другое слово в ИТ, у нас наладились отношения между закачиком и технической командой, мы “быстрее бежим», и меньше делаем дорогих ошибок, но прибыль что-то у компании не растет».

А еще и затраты стали больше, правда ведь? Консультанты, агенты по трансформации, повышение зарплат и так далее. А чего вы ждали-то? Вы разве к ИТ-отделу ходите за финотчетами?

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

И с этими словами тоже нужно познакомиться, потому что там где заканчивается Agile, начинается Business Agility — а это уже история для отдельной статьи.

В чём же суть Agile

Один из авторов манифеста (Дейв Томас) после его создания не посещал конференции, мероприятия, не интересовался тренингами по Agile. В рамках своего знаменитого выступления «Agile мёртв» он описал, что и как надо делать.

Что делать

Как делать

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

Что для этого нужно

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

И эти правила не персональные, они должны работать на уровнях:

Так что берите их на вооружение и начинайте меняться уже сегодня.

Источник