Термин Agile означает «гибкость», появился как более совершенный метод разработки ПО в 2001 году, став плодом встречи 17 людей из мира IT. На той же встрече был сформулирован знаменитый «Agile-манифест», закрепивший принципы и ценности Agile.
Методы Scrum, OKR, Kanban по сути являются разновидностями Agile-подходов и каждый из них имеет своих адептов, последователей и почитателей, благодаря которым методы доказали свою эффективность, и вышли далеко за пределы IT-сферы.
И действительно, каждый в отдельности и все вместе эти методы великолепны, они просты, понятны и эффективны:
- Scrum – это формула 3-5-3: три роли, пять мероприятий, три артефакта.
- OKR (Objectives and Key Results) – это четыре суперсилы: приоритизация и обязательства, синхронизация и прозрачность, мониторинг, стремление к выдающимся результатам.
- Kanban – это 9 ценностей: прозрачность, баланс, сотрудничество, клиенториентированность, поток, лидерство, понимание, согласие, уважение.
Конечно, это общее представление. Внутри методов все это раскладывается на различные практики, способы и инструменты, тем не менее, выглядит достаточно простым. Казалось бы, вот она пресловутая «волшебная палочка», которая раз и навсегда решит все проблемы компании.
И как это бывает, на зарождающемся хайпе пышным цветом расцвело «инфоцыганство», появилось множество консультантов, специалистов и «экспертов» по внедрению, с одной стороны. С другой, любознательные сотрудники хороших компаний, прочитав одну-две книжки по теме, или прослушав курс от «инфоцыган», добросовестно пытаются что-то изменить в компании. Это в любом случае хорошо, учиться всегда хорошо. Плохо, что неудачные попытки вызывают разочарование, отторжение и, в лучшем случае, откат к привычным схемам работы.
Две рекомендации для начинающих изучать Agile-подходы
- Не стоит отчаиваться. Даже отцы-основатели Agile-методов прямо говорят, что далеко не всегда все получается с первого раза. И это нормально.
- Учите матчасть.
Если с первой рекомендацией все в принципе понятно, то вторая требует комментариев. Нужно абсолютно ясно понимать, что внедрение любого подхода Agile – это не просто смена инструмента, это изменение всего способа ведения дел, изменение архитектуры компании как системы. Наиболее продвинутые понимают это, но, как правило, допускают одну из ошибок: проводится либо попытка радикального внедрения (сломать все и сразу), но получаются руины, либо внедрение пилотного проекта, но при этом проекту подчинены все ресурсы (часто это даже не замечается), и потому мультиплицировать опыт не удается.
Причины провалов Agile-подходов
Если говорить в контексте подходов Agile, прочтение всех книг и прохождение всех курсов по теме совсем не гарантируют результат, хотя и не отменяет возможность успеха. Авторы и разработчики Agile-методов безусловно умные и талантливые люди, методы эффективны и просты, множество компаний по всему миру успешно используют их в работе. Но так ли все просто на самом деле?
Никто из авторов методик не отрицает, что в их основе лежат так называемые «бережливые технологии». К сожалению, в России сформировалось очень узкое представление о том, что это такое. Во многом благодаря вошедшему в деловой обиход термину «бережливое производство», который резко сужает фокус восприятия на одной отрасли. Между тем это полноценная философия и концепция управления, имеющая в качестве фундамента строго научную основу. Компания Toyota, например, которая ассоциируется с термином «бережливое производство», на этом фундаменте построила свою уникальную систему управления.
Сами японцы искренне недоумевают, когда многочисленные жаждущие последователи пытаются изучить и скопировать инструменты и методы, которые каждый раз были разработаны для конкретной и всегда уникальной ситуации. И при этом не пытаются понять сути.
Нет цели пускаться в теоретические философствования и описание концепции бережливого способа ведения дел. На эту тему имеется масса источников и достаточно много (но очень мало для России) специалистов. Вдумчивый читатель даже при беглом серфинге источников увидит, как много общего между Agile-подходами и lean-технологиями. Но основная концепция все же была сформулирована именно в lean manufacturing и даже научно обоснована.
Бережливые технологии также раскладываются на бесчисленное множество способов, методов, инструментов. Проблема в том, что каждый раз это уникальная история, поэтому простое копирование с учебника или с реальной, но чужой ситуации не гарантирует успех. Это одинаково справедливо как для бережливых технологий, так и для Agile-подходов.
Можно возразить: если не пробовать, то никогда и не получится. Это справедливо и правильно. Но просто делать что-то, пусть даже с энтузиазмом, не понимая, что ты делаешь, это дорога в никуда. Все советы типа «просто возьми и сделай это» хороши разве что на этапе стартапа. При управлении компанией этот принцип хорош, когда хотя бы один человек (в бережливых технологиях его называют «агент перемен») не просто знает, что нужно делать, а понимает – почему.
Носители знаний – люди. Источник инноваций – люди. Из всех трех элементов, которыми следует управлять (люди, процессы, технологии), люди – наиболее уязвимый, проблемный, но и самый ценный актив. Поэтому, поддавшись веянию моды или осознав необходимость перемен, проведите экспресс-аудит своего основного актива, прежде чем что-то внедрять.
Аудит перед внедрением гибких методологий
- Руководителям высшего звена стоит начать с себя и предельно честно ответить на вопрос – готовы ли лично вы меняться, потому что просто мониторить не получится. Готовы ли вы не сломаться при возможных многократных неудачах и не дать приказ отступать.
- Какими знаниями обладает компания. Есть ли внутренний «агент перемен» или вы нашли внешнего? Это должен быть человек, который не просто знает спецтермины и по памяти может перечислить все принципы и ценности, а который на глубинном уровне понимает и принимает их. Тут сложно. С одной стороны, нет, наверное, таких методов оценки, чтобы выявить такие компетенции, с другой, даже наличие опыта еще ничего не гарантирует. Но если вы точно готовы меняться, то просто поймете – ваш человек или нет.
- Оцените потенциал своей команды, каждого сотрудника. Вам понадобится стартовая команда из людей, которым как минимум не все равно.
- Оцените ресурсы. Внедрение любого метода, как правило, малозатратно, но даже небольшие вложения, например, покупка магнитно-маркерных досок, иногда вызывает сложности.
Подобных списков в разных вариантах может быть множество, но только обладая знаниями, готовностью, командой и ресурсами (во всех смыслах), можно рассчитывать на успех.
Собственно, это и есть обратная сторона провалов и неудач. Если компания не обладает знаниями, она просто не знает, что и как делать, в лучшем случае пытается скопировать чужой опыт. Если не готовы руководители, то вообще не стоит ничего начинать. При этом не следует путать декларации с реальной готовностью. Если дела настолько плохи, что нет людей, искренне заинтересованных в развитии и переменах (или вы их просто не видите), то в одиночку вы скатитесь либо до административно-командного стиля (если ваше положение в компании достаточно высокое) и будете насиловать систему, пытаясь что-то изменить, либо станете «белой вороной» и поводом для иронии и насмешки. С ресурсами все не так плохо – их можно создать, но многие причины провалов часто обусловлены отсутствием ресурсной поддержки.
Учите матчасть
Общая идея этой статьи такова: если вы пытаетесь внедрить Agile-подходы, учите матчасть. А матчасть в данном случае – это бережливые технологии и их фундаментальная основа. Это сформирует необходимый уровень знания и экспертизы, которые резко увеличит шансы на успех. Не поддавайтесь искушению простотой, если бы все было так просто, то все компании были бы успешны и счастливы. Не бойтесь экспериментировать, не бойтесь привлекать внешних специалистов – это всегда свежий взгляд на способ вашего ведения дел. Полагайтесь на людей!
Также читайте:
Не-а, мы не узурпировали. Я ж и пишу - мы породили. Это узкое горло взаимоотношения заказчик-разработчик всегда очень тяжело проходилось. С тех времён идут эти всякие блок-схемы, Р-схемы и пр и др. Заказчик ещё не знает, что он хочет, разработчик ещё не понимает, как это сделать. Вот и стали появляться много лет назад сначала прототипирование, потом экстремальное программирование и пр и др. И вот он во всей красе - Agile. Появилась возможность расшить многие узкие места. Как это применить в бизнесе, я просто не знаю и не готов с Вами дискутировать именно и-за недостатка моего опыта.
Но, повторюсь, для ИТ эджайл не панацея. На каком-то этапе он лучше, а на каком-то хуже. Мы сейчас, например, работаем с разработкой и внедрением некой федеральной системы. Засовывать туда эджайл - только пустая трата ресурсов. Но когда переходили на новую версию, то там он был просто в масть.
Пока надеюсь, что это просто обмен мнениями на тему, которая интересна многим - еще раз спасибо автору статьи!
Я не теоретик и очень далёк от теологии.
Мой вопрос был связан с утверждением, что SCRUM идеально подходит для ... . Есть такой статистики под руками нет (я пока ничего подобного не видел) - вопрос снимается.
Выбор инструментов - дело вкуса и привычки. Да, будем использовать здравый смысл, куда нам без него.
С этим я не могу согласиться. Agile Manifesto - это совсем не о терминах. Это пересмотр некоторых базовых концепций разработки ПО. Достаточно посмотреть на жизненный опыт и книги его авторов.
Думаю, что пока мы не говорили о главном, и это непосредственно связано с темой статьи. К моменту формулирования Agile Manifesto в отрасли накопилось достаточно ( ... слишком много ...) примеров провалов крупных и важных проектов разработки ПО, причём от квалификации исполнителей (включая лидеров отрасли) соотношение успешных и проваленных проектов разработки напрямую не зависело. Количество соответствующих публикаций многократно превышает мои возможности их перечислить, но можно начать с IEEE Software, IEEE Spectrum ... и статей классиков жанра. Упомянутая Вами выше в ветке статья об итерационном планировании говорит о том же.
Среди важнейших причин провалов исследователи и эксперты обычно выделяли две - проблемы Scope и Communication. В двух словах, Waterfall как подход к планированию разработки всем понятен и практически идеален со многих точек зрения - при одном допущении. Мы фиксируем исходные данные и требования заказчика практически на весь срок разработки, если не на весь жизненный цикл проекта. В строительстве и многих других отраслях такое отлично работает, иначе дома бы не строились и ракеты бы не летали. Но, увы, не в крупных, долгих, сложных и комплексных проектах разработки ПО. Хотя для менее крупных и сложных проектов всё заметно лучше или просто хорошо.
Понятно, что в крупной разработке при изменении хотя бы части требований через 6-12 месяцев после запуска проекта ситуация для менеджеров проекта и разработчиков становится сложной, если не критической. Затраты постоянно растут, время идет, но достигнутый промежуточный результат сложно оценить, а еще сложнее понять, что же нужно сделать для успешного (с точки зрения заказчика) завершения проекта. Иногда итоги многолетней работы описываются в публикациях как Epic Fail.
Интересующиеся могут посмотреть на идеи, например, Barry Boehm, Robert Charette или Lister / DeMarco. Источники мудрости.
В качестве возможного решения предлагается сразу признать, что исходные данные и требования для разработки в полном объеме собрать невозможно. Жаль, это реальность. Поэтому процесс разработки изначально планируется как итерационный с минимальным временем каждого шага (вплоть до одного дня) и некими формализованными процедурами общения, согласования и тестирования, но это уже не так важно. Зато в каждый момент времени мы знаем, где находимся. Заказчик (внешний или внутренний) уточняет, куда мы дальше движемся, вносит необходимые коррективы и дает новые данные по мере появления.
Все выглядит совсем неплохо, несмотря на более высокие накладные расходы, но и при таком подходе есть пара проблем - кто, собственно, знает, что и в какой момент считать успешным результатом проекта и завершением разработки? Насколько полученный таким образом продукт отвечает требованиям рынка? Как там с качеством? И так далее.
Возможно, это частичный ответ на вопрос автора статьи, вынесенный в заголовок.
Отличная идея, почему нет. Тема необъятная, деталей сколько угодню.
Абсолютно верно.
Почему бы не считать, что Agile при разработке ПО - это просто один из подходов к управлению проектом среди прочих возможных вариантов. А выбор на уровне проекта делается с максимальным учетом всех известных общесистемных требований. Всё остальное - вопрос исполнителя.
Именно! А не новая концепция управления бизнесом вообще.
Я уже устал спорить с адептами «святого эджайла», готовыми воткнуть эту технологию везде и всюду в бизнесе.
Если обратится к первоисточнику этой концепции статье Ройса Уинстона, которую я приводил, в ней был заложен цикл редизайна (3-4 шаги), все чего не хватало в этой модели, это указать, что это не прекращающийся процесс и выбор периода планирования определяется динамичностью окружения. Он писал об этом в дальнейшем, и очень расстраивался когда его назвали отцом водопада. И тогда все встает на свои места:
И тогда вопрос, Agile Manifest это новое знание или маркетинговый шаг?
Повторюсь, Agile это не технология, это подход, образ мысли. Конечно же в стабильном бизнесе с постоянным окружением без амбиций к кратному росту использование этого подхода бессмысленно.
Заставь дурака богу молится, он и лоб расшибет. Не сотвори себе кумира. 12 заповедей Agile определяют очень общие принципы и имеют множество толкований... Никто же не ожидает что 10 христовых заповедей решат все мировые проблемы. Для этого есть кодексы, законы и регламенты.
Agile - это не новая концепция управления бизнесом, это реинкарнация старой доброй артели, а она совсем не годится для массового производства. Но для того что бы сварганить MVP на коленке или сделать интернет-магазин.
Для массового производства и крупных сложных проектов предлагается подход Business Agility, который развивает идеи Agile, обогащая их преимуществами Lean Production. Этот подход при грамотном применении дает выигрыш любому бизнесу. Создатели SAFe например говорят, нет необходимости изменять всю компанию, Lean-Agile это способ создать вторую операционную систему в бизнесе, которая позволит крупной компании не ломая иерархию повысить эффективность процессов создания новой ценности.
Возможно, дискуссия о правильных подходах к разработке началась гораздо раньше. Вариантов модификации Waterfall предлагалось много - и по вполне понятным причинам.
Но исходный вопрос остается. Зачем вообще нужен редизайн и циклы, если вы сразу можете собрать все требования и не менять их до завершения проекта? Для разработчиков это идеальный вариант и минимальные накладные расходы, для заказчика - минимум затрат и понимание, что он увидит на финише. В коротких проектах так бывает.
А вот в случае невозможности такой работы все остальные варианты планирования являются субоптимальными и дискуссионными. Для меня ответ зависит от многих деталей и особенностей проекта. Решение нужно принимать с открытыми глазами.
Есть и другие ответы. Для меня Agile Manifesto звучит как неформальное предложение отрасли еще раз как следует подумать и подведение практикующими ветеранами некоторых промежуточных итогов.
Работы же меньше не становится. Вопрос в том, как в очередной раз не наступить на уже известные грабли.
Вотимеено!
"Поступила установка весело встретить Новый год".
Мне сложно как-то иначе интерпретировать слова авторов Agile Manifesto:
Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.
Это первый принцип. Скажем, третий принцип звучит так:
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Возможно, если читать принципы в обратном порядке и примерно до середины, то можно сделать другие выводы. Но всегда можно вернуться к оригиналу:
https://agilemanifesto.org/principles.html
А вот и сам манифест. Авторам не потребовалось много слов.
"Узкое горло взаимоотношения заказчик-разработчик всегда очень тяжело проходилось".. Дабы не обидеть Вас Анатолий подчеркну, что выскажу исключительно свое мнение, основанное на опыте (может опыт не очень у меня)).
Так вот на мой взгляд, это самое "узкое горло" возникает потому что разработчики даже не пытаются понять и погрузиться в бизнес клиента. Дело, как правило, ограничивается встречами с руководителем-заказчиком-плательщиком, который зачастую очень далек от реальности. Далее взаимодействие осуществляется с лицом или лицами ответственными за внедрение чего-либо и в очень редких случаях с непосредственными исполнителями.
В результате происходит попытка автоматизировать / оптимизировать хаос, что в принципе невозможно.
Справедливости ради нужно сказать, что и сами заказчики ведут себя как нищие на восточном базаре. Надо это, надо то, а ещё вот это. И все это лучше бесплатно.
В результате с одной стороны меняются требования и ничего хорошего в итоге не получается, с другой проекты затягиваются и превращаются в незавершенное производство, потраченное время, неудовлетворенность друг другом.
Может быть в каких-то серьезных разработках все происходит иначе, но в проектах, например, по автоматизации с которыми я сталкивался все работает точно так.