Agile, scrum, kanban: в чем разница и для чего использовать?
Главный редактор RB.RU
Если раньше офисы модно было обустраивать «по фэн-шую», то теперь — исключительно «по эджайлу». Agile – это не только цветные стикеры, на которых удобно отмечать ход работы (стикеры, скорее, стоит относить конкретно к подходу kanban). А ведь есть еще и scrum – он тут при чем?
Специально для тех, кто запутался в терминах, мы кратко разобрали эти понятия и спросили экспертов, зачем компании переходить на новую систему.
Определение
Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.
Agile возник в IT-среде, но затем распространился и в другие сферы – от промышленной инженерии до искусственного интеллекта.
Смысл Agile сформулирован в Agile-манифесте разработки ПО: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».
Agile-манифест – главный документ всех «гибких» подходов к разработке. Он был создан в 2001 году группой энтузиастов-программистов, которые хотели понять, что именно лежит в основе разработки востребованного и полезного IT-продукта. Agile предполагает, что при реализации проекта не нужно опираться только на заранее созданные подробные планы. Важно ориентироваться на постоянно меняющиеся условия внешней и внутренней среды и учитывать обратную связь от заказчиков и пользователей. Это поощряет разработчиков и инженеров экспериментировать и искать новые решения, не ограничивая себя жесткими рамками и стандартами.
К отдельным agile-подходам относятся scrum и kanban.
Scrum – это «подход структуры». Над каждым проектом работает универсальная команда специалистов, к которой присоединяется еще два человека: владелец продукта и scrum-мастер. Первый соединяет команду с заказчиком и следит за развитием проекта; это не формальный руководитель команды, а скорее куратор. Второй помогает первому организовать бизнес-процесс: проводит общие собрания, решает бытовые проблемы, мотивирует команду и следит за соблюдением scrum-подхода.
Scrum-подход делит рабочий процесс на равные спринты – обычно это периоды от недели до месяца, в зависимости от проекта и команды. Перед спринтом формулируются задачи на данный спринт, в конце – обсуждаются результаты, а команда начинает новый спринт. Спринты очень удобно сравнивать между собой, что позволяет управлять эффективностью работы.
Kanban – это «подход баланса». Его задача – сбалансировать разных специалистов внутри команды и избежать ситуации, когда дизайнеры работают сутками, а разработчики жалуются на отсутствие новых задач.
Вся команда едина – в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др.
Главный показатель эффективности в kanban – это среднее время прохождения задачи по доске. Задача прошла быстро – команда работала продуктивно и слаженно. Задача затянулась – надо думать, на каком этапе и почему возникли задержки и чью работу надо оптимизировать.
Для визуализации agile-подходов используют доски: физические и электронные. Они позволяют сделать рабочий процесс открытым и понятным для всех специалистов, что важно, когда у команды нет одного формального руководителя.
Примеры употребления
Один из принципов Agile стоит на личной ответственности человека, а не на отлаживании внутренних процессов.
Когда в работе с профессиональными командами мы используем Scrum, чаще всего мы выбираем цикл длиной в 2–3 недели с ретроспективными собраниями, которые позволяют держать все под контролем.
(Из интервью «Ведомостей» с Фрэнком Сосьером, коучем компании Freestanding Agility)
Главная идея Kanban – визуализация рабочего процесса. Она заключается в создании физической панели, на которой можно наглядно отмечать прогресс.
Если говорить о том, что такое agile, я бы ограничился такой фразой – это набор ценностей, в рамках которых мы строим свою работу с продуктами, с процессами внутри организации.
(Управляющий партнер ScrumTrek Алексей Пименов в статье на Rusbase)
Слово экспертам
В зависимости от задач мы применяем разные методы в рамках философии – agile, scrum, kanban. Scrum позволяет развить в сотрудниках необходимые качества – проактивность, самостоятельность, организованность, коммуникабельность и дальновидность. Основной смысл метода – это выполнение задач в самоорганизующихся командах, где у каждого есть своя роль и каждый несет ответственность за свою часть работы. Используя scrum, мы проводим опросы персонала, составляем графики ожидаемой скорости выполнения задач. Agile мы используем во внутренних коммуникациях. Недавно провели очередной спринт по ликвидации опозданий сотрудников. Все начальники и специалисты, задействованные в проекте, провели целый день на совещании, обсуждая достижения, проблемы и предстоящие задачи в новом спринте. Сейчас мы активно внедряем в компании метод kanban. Цель внедрения kanban – повысить гибкость производства, лучше приспосабливаться к изменяющимся требованиям рынка. На практике метод помог нам добиться соответствия между складскими запасами и реально используемыми в производстве продуктами.
Важный момент: agile-методология – это общее направление, а kanban и scrum – уже ее разновидности. Мы используем связку scrum + waterfall, а также дорабатывали в течение года саму agile-доску. Главная причина использования: прозрачность и простота. По сути, это получается тот же самый конвейер Генри Форда: переход задачи от статуса к статусу со сменой исполнителя, поэтому основным принципом к самой agile-доске является уже простота. Мы используем agile как непосредственную часть нашего workflow, поэтому все проекты, от брендинга и разработки сайтов и вплоть до нашего стартапа по AI и нативной рекламе NativeOS, в бюро Chernika ведутся как раз по данному workflow. Работающий продукт важнее подробно прописанной документации. Это не говорит о том, что мы не ведем никакую документацию, нет. Это скорее взгляд в сторону эффективности с ударом по излишней бюрократии.
Scrum принес в нашу команду ритмичность и понимание — успеваем или не успеваем в срок. Мы видим скорость работы команды, нет ощущения постоянного факапа. Раньше были ситуации, что перед жесткими релизами scrum куда-то пропадал и все начинали просто фигачить — сейчас у нас это пропало, есть постоянное ощущение, что успеваем в срок. Если появляются риски, мы обсуждаем их с PD на ранних этапах, корректируем план или уменьшаем объем задач каким-то образом. Работа стала прозрачнее, рабочий день стал укладываться в 8-часовую норму и, по ощущениям, мы стали успевать больше. Мы понимаем, что когда у тебя есть ощущение, что ты не успеваешь, чувствуешь, что надо работать больше — это очень плохо влияет на продуктивность, от этого надо избавляться.
Для наглядности и открытости работы отдела разработки мы повесили специальную доску с пометками “to do”, “in progress”, ”review”, ”test”, “done”, где все члены команды наклеивают стикеры с задачами (в колонке “to do”), а по мере их выполнения перемещают в последующие пункты. И счастливый финал – конечный пункт “done”. Это помогает составить общую картину и дает возможность видеть, над чем работает каждый участник. Очень важный момент метода (и организации рабочего процесса): после утверждения всех задач (“to do”), список блокируется на внесение. Так новые поступающие задачи не отвлекают от процесса и не тормозят работу. Все участники также оценивают каждую задачу на предмет временных и материальных затрат, которые потребуются на выполнение. И вишенка на торте – ежедневные встречи в определенное время (Daily Scrum), где каждый член команды коротко рассказывает о том, что собирается сделать сегодня, что сделал вчера (и столкнулся ли с какими-то препятствиями). Это важно на пути к долгосрочным задачам – именно так можно вовремя понять, что пора сменить стратегию.
Scrum мы внедрили с двух попыток, потому что всем, от команды до пользователей, хочется иметь более прогнозируемый результат. В этом плюс методологии – четкие ритмы упорядочивают коллектив, повышают общий уровень знаний о проекте. Как следствие, результат становится более прогнозируемым, в том числе для наших «стейкхолдеров» – пользователей. Командная работа также повышает ответственность: все получают бонус, только если команда выполнила поставленные на определенном этапе задачи.
Agile – это философия, scrum – структура, waterfall – метод, kanban – система управления. Scrum и kanban – варианты agile, но у них есть некоторые явные различия. Методика scrum требует фиксированных ролей, тогда как у kanban нет необходимых ролей. Scrum основана на итерациях, объединяющих планирование, оптимизацию процессов и выпуск. В kanban это можно делать регулярно или каждый раз, когда вам нужно. Команда scrum требует оценки своей работы, тогда как команде kanban это не нужно.
Что почитать по теме?
Поиск инвестора онлайн стал намного проще. Узнай как
Текст: Александр Петров.
Видео по теме:
Scrum и Agile для чайников
Комментарий Котиков
Для начала. Scrum и Agile — в чем разница? Если коротко, Agile — это философия, семейство гибких подходов к разработке ПО. Scrum — один из таких подходов. У него есть братик — Kanban. Он тоже подход, используемый в Agile.
На этой неделе я прошла двухдневный тренинг по Agile/Scrum (произносится «эджайл» и «скрам»). По гибким методологиям разработки программного обеспечения написано много заумной и не очень литературы, многое я читала. Но только после двухдневного погружения в тему у меня наконец собралось базовое понимание предмета, из которого я пишу эту заметку.
Эджайл и скрам помогают организовать процесс работы в команде так, чтобы выпускать интересный пользователю продукт регулярно и часто.
В некоторых банках путь идеи к пользователям благодаря эджайлу сократили с двух лет до шести месяцев — в других компаниях шесть месяцев цикла разработки сжались в три. В наше суматошное время это истинное конкурентное преимущество, особенно для малых игроков.
Принципы скрама можно применить совершенно ко всему: например, к работе над творческим продуктом. Это, конечно, не «канонический эджайл», скрам-евангелисты будут скрежетать зубами, зато ваши процессы будут двигаться бодрее. Шашечки или ехать?
Кое-что из эджайла и скрама можно взять даже в индивидуальную работу. Обеспечить регулярную публикацию постов, отмерять нагрузку на исполнителя, оценивать будущие задачи по времени и не забывать анализировать качество проделанной работы — смотрите, за нас уже всё придумали. Осталось внедрить.
Эджайл
(англ.agile —«проворный, шустрый, сообразительный»)
Концепция гибкости:
Подставьте свой вид деятельности вместо слова «разработка» — и эти принципы станут близкими и понятными.
«Работающий продукт — основной показатель прогресса», «простота как искусство минимизации лишней работы» и «люди и взаимодействие важнее процессов и инструментов» — правда, звучит разумно?
Книжку «Открывая организации будущего» Фредерика Лалу я читала совсем недавно. Вполне бодрый подход ко всем отраслям на свете
Скрам
(англ. scrum — толкотня в борьбе за мячик в регби)
Тут стоит напомнить, что это моя личная и субъективная точка зрения на скрам. Здесь я размышляю о применимости элементов скрама как в творческих проектах, далеких от IT, так и в индивидуальной работе (скажем, над блогом). Много точных деталей для этого придется упустить; я стараюсь сохранить простоту текста и не перекормить читателя терминологией.
Жесткость скрама заключается в структуре. Есть некий набор подходов, работающих вместе лучше, чем по отдельности. Вытащить что-нибудь и заиспользовать вам, я надеюсь, никто не запретит.
Обычно скрам происходит там, где есть некий продукт, имеющий ценность для пользователей и заказчиков, и нужно как можно быстрее на пути к цели понимать, в том ли направлении мы сейчас бежим — или надо корректировать курс. Формат скрама позволяет выпускать очередную версию чаще, регулярно получать обратную связь и быстро дорабатывать продукт, а также — улучшать процесс работы.
Если вы работаете в команде, скрам предписывает всем участникам процесса стремиться к взаимозаменяемости, к способности «подхватить» провисающую задачу, если сосед заболел, к обмену навыками и коллективной ответственности за продукт. Индивидуализма в скраме мало. Решения принимаются коллективно (по строгим принципам), никто не может надавить и заставить выбрать другое решение, если команда уверена, что остановилась на верном.
Поэтому даже если мы все уверенно побежали в неправильном направлении, у нас будет в конце спринта возможность его скорректировать и починить то, что нас направляет не туда. Команда в скраме самоорганизующаяся и самонастраивающаяся.
Команда в скраме
Стандартный размер скрам-команды — 7 плюс-минус 2 человека. То есть от пяти до девяти. Бывает скрам-масштабирование: можно из 25 команд состроить систему работы над гигантской задачей. Но основная единица скрама — команда.
В каждой команде есть:
Устройство спринт
Работа в скраме состоит из спринтов. Все спринты устроены одинаково. Предполагается, что с каждым следующим спринтом команда становится всё сыграннее и эффективнее. В скраме учишься на своих ошибках, но быстро — каждый спринт анализируешь, что именно натворил и как хочешь это исправить.
У продакт оунера есть список идей от бизнеса для осчастливливания пользователей. Он называется «продакт бэклог» (product backlog, список продуктовых идей). В нем идеи отсортированы по важности и значимости.
В каждом спринте есть спринт бэклог (sprint backlog, список задач на спринт) — отсортированный список идей, которые команда решила сделать за ближайший спринт. Смысл скрама в том, что команда сама оценивает сложность каждой задачи и решает, какие задачи войдут в очередной спринт.
Задача в спринте имеет известный команде вес (известно, сколько времени на неё уйдет), к ней прикреплен исполнитель, она является понятной и важной. Если неизвестно, сколько времени уйдет на задачу, нужно её разбить на более мелкие части.
В начале своей жизни команда всегда плохо планирует. Это объективная реальность. Но она ведет статистику того, что ей удается сделать за спринт, и со временем планирует всё точнее. Ей помогает итоговая встреча спринта — ретроспектива. На ней можно обсудить слабые моменты уходящего спринта и придумать способы делать по-другому.
Обычно в спринт влезает 5 плюс-минус 2 идеи. Если идеи слишком большие, команда их дробит так, чтобы в каждом спринте можно было что-нибудь маленькое, да показать.
В скраме идеи называются юзер-сториз (user stories, истории про пользователей) и формулируются так: «Я как (роль?) хочу (что?) для того, чтобы (зачем?)». Таким образом команда видит не только функциональность, но и смысл её создания, причем для конкретной роли: пользователь, заказчик, покупатель.
Результатом спринта всегда является что-то, что можно показать. Показывает работу команда на демо в конце спринта.
На мой взгляд, скрам-процесс похож на работу над коллективным блогом. Такой процесс помог бы соблюсти регулярность, свести воедино экспертизу авторов и не набирать столько, что не успеешь сделать.
Структура спринта
Спринт начинается с планирования: команда садится и обсуждает: вот эту идею берем, вон ту не берем. В IT этот процесс может затягиваться на пару часов, потому что обсуждение идет вплоть до деталей. В случае работы с блогом это может превратиться в обсуждение тем и плана статей, которые потом останется сесть и написать — понимая, что пишем, когда и зачем.
Каждый день есть стендап-митинг (stand up meeting, совещание стоя) на 15 минут. Делать его стоя важно: если кто-то заболтается, остальные красноречиво будут переминаться с ноги на ногу и чесать ухо. Можно использовать какой-то предмет, чтобы говорил в один момент времени только один участник, и передавать его по кругу.
Каждый участник стендапа по очереди отвечает на три вопроса:
Все завязывающиеся в процессе детальные разговоры уходят за пределы стендапа. Стендап — это точка, в которой можно поймать проблемы или узнать, что мы с коллегой почему-то делаем одно и то же одновременно, а значит — кто-то из нас может заняться чем-то другим.
Вообще поддержанием всех вот этих четких правил поведения должен заниматься скрам-мастер. Это обычно идеологи технологии, верящие в нее и готовые выстраивать процесс для максимальной эффективности проведенного вместе времени. Без скрам-мастера процессы выродятся в минимально возможные, потому что человек ленив и экономичен.
В конце спринта происходит демо (demo, демонстрация) с показом того, что удалось создать в течение спринта, спринт-ревью (sprint review, обзор спринта) с пересмотром продакт-беклога и разговорами о том, ЧТО мы делаем, а также ретроспектива (retro) — что мы делали не самым лучшим образом весь спринт и хотим улучшить далее — о том, КАК мы это делаем.
«Если бы у меня было восемь часов для того, чтобы срубить дерево, я бы шесть часов потратил на заточку топора». (приписывается лесорубу и президенту Аврааму Линкольну)
«Scrum головного мозга»: что такое Agile и где его применять Статьи редакции
Гендиректор сервиса для управления процессами в команде Kaiten.io Вячеслав Цырульник написал в своём блоге на Medium колонку о том, что такое манифест Agile, зачем он нужен компаниям и как лучше трансформировать бизнес. Редакция vc.ru публикует заметку с разрешения автора.
Вы, наверное, уже сталкивались с дискуссиями по теме Agile в интернете. То рассказывают про Scrum — революционный метод управления проектами, то говорят, что 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 мёртв» он описал, что и как надо делать.
Что делать
Как делать
В случае, если существует несколько способов для достижения приблизительно одной цели, выбрать тот путь, результаты которого будет проще изменить в будущем.
Что для этого нужно
Отвага и смелость. Потому что вы будете ошибаться — часто и много. Но чем быстрее вы научитесь ошибаться, тем меньше будут потери от этих ошибок, и тем быстрее вы научитесь корректировать свой курс в правильном направлении.
И эти правила не персональные, они должны работать на уровнях:
Так что берите их на вооружение и начинайте меняться уже сегодня.
