Термин 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 длится уже достаточно времени, чтобы появились такие клиенты.
Для IT это все уже на более продвинутом этапе, и можно использовать для очень больших проектов не только из-за этого опыта. Перспективы развития отрасли находятся в области развития сервисов, а это позволяет разбить многие проекты на множество небольших не "слишком связанных" задач. Не буду дальше углубляться :) - это понятно.
Предполагаю, что для многих других предметных областей, есть ограничения, и можно будет использовать только на каких-то этапах разработки. В общем, скорее будет "смесь" методов.
Понятно, что в первую очередь некоторые технологии Agile точно будет перспективно использовать на первых этапах проекта. Для маркетологов - это золотая жила :). И на тех этапах проекта, на которых требуется изобретательская деятельность.
Можете пояснить?
Как именно можно разбить проект (?) на множество не слишком связанных задач? Что мы изначально хотели? Что мы получили?
Посмотрите на многие IT проекты, которые точно используют Agile. Они построены как отдельные сервисы, которые взаимодействуют с одной платформой.
Мы упростили задачу построения сложной системы.
Agile - это не самоцель, а способ справляться со сложными проектами, новыми возможностями, которые включаются, как включается "электрическая вилка в розетку".
Слабая связность является признаком хорошо структурированной системы.
Похоже, что Вы затронули другие темы.
Мы не обсуждаем (вроде бы) то, что Agile - самоцель. Статья темы - о проблемах внедрения некоторых подходов и концепций.
Я не могу посмотреть на проекты Сбера и интересующие меня детали и документы - это внутренняя информация, что вполне логично.
Для разбиения большой системы на части (декомпозиция) и планирования параллельных работ Agile не нужен и не обязателен. Об этом неплохо знают, например, строители и конструкторы. Инженеры такое делают десятки, если не сотни, лет.
Детали взаимодействие сервисов (на каком уровне?) и некой общей платформы - совершенно отдельный технический вопрос. Например, интеграция отдельных компонентов ПО с использованием API и слоя Middleware при построении больших систем преследует те же цели, что и развитие какого-то функционала, предлагаемого как SaaS, вокруг специально написанной для этого платформы (пример PaaS).
Это, в частности, позволяет независимым разработчикам, если платформа открыта, добавлять и продавать свои модули. Но используют ли они в проектах разработки какой-то из вариантов Agile или нет - пользователи не знают, и им это не так важно. Лишь бы работало.
P.S. Личная просьба пользоваться кнопкой/ссылкой "Цитировать" при цитировании вместо частичного копирования. Иначе я могу пропустить Ваш комментарий или вопрос, сайт без режима цитирования о них не сообщает.
Евгений, у вас был вот этот конкретный вопрос, и я на него ответил.
Еще была целая дискуссия на эту тему и вы прпустили вот это
- проблем связаанных с формулировкой требований к проекту.
Agile имеет преимущества в IT - потому что по своей сути это есть маркетинг в чистом виде, позволяющий воплотить все реальные пожелания клиента. И даже те хотелки, которые он сам не смог сформулировать в самом начале проекта. И сделать это в реальные сроки и за реальные для клиента деньги. Это отвечает требованиям рынка разработки ПО.
Я прочитал Ваш комментарий. И совершенно согласен с тем, что в нашем мире нет ничего идеального. Это не новость, которую нужно специально обсуждать. Как и не ответ на какой-либо конкретный вопрос.
Авторы Agile Manifestio, насколько можно видеть, говорили совсем о другом (см. выше в ветке). Я не нашел там ничего об исполнении всех фантазий клиента. И Ваш тезис о том, что Agile - это маркетинг, нуждается в обосновании.
Евгений, вы же всю дискуссию высказываете свое мнение? Этот манифест о ценностях и принципах разработки. Если внимательно вчитаетесь, найдете в Манифесте соответствие.
И мне не надо доказывать цели, которые ставит маркетинг. Цели Agile совпадают с целями Маркетинга, а методы со многими Маркетинговыми методами разработки нового продукта.
Это достойный ответ Маркетинга в разработке ПО. Вы можете представить себе это так - когда у авторов Манифеста появилось маркетинговое мышление, они его и написали.
Выше я уже высказал своё мнение о причинах появления Agile Manifesto. Более важно, что это не только моё мнение. С мышлением его авторов мне тоже что-то понятно, достаточно почитать их книги и посмотреть на их проекты. Впечатляюще по любым меркам.
Но Вы вправе искать и любые другие объяснения, аналогии и причинно-следственные связи. Маркетинг - так маркетинг, Вам виднее. Не вижу с этим никаких проблем. Надеюсь, это слово еще можно писать с маленькой буквы - или я что-то упускаю?
Евгений, это слово "важно" больше говорит о том, что это не ваше мнение. Для вас оно важно.
Но насколько правильно поняли это чужое мнение?
Если точнее, это не только моё мнение. Никаких открытий я не делал. Но, безусловно, я могу ошибаться в любом месте и в любое время и всегда благодарю, если меня поправляют.
Правильно ли я понимаю то, что я читаю, и уверен ли я в том, что делаю правильные выводы из прочитанного? Вас именно это интересует? В данном случае это легко проверить - если хотите.
Есть авторитетные отраслевые источники, включая упомянутые мной в этой ветке. Есть многочисленные публикации о причинах успеха и неуспеха крупных проектов разработки ПО. Есть книги и выступления авторов Agile Manifesto. Можно начать с Кента Бека, если Вам нравится XP. У него много и других идей вокруг разработки, тестирования и актуальных проблем отрасли.
Моё мнение постепенно сформировалось после знакомства с перечисленным, это было не сегодня и не для этой дискуссии. Нужны ссылки - скажите.
Если Вы можете трактовать всё это как-то иначе и видите связь (совпадение целей!) Agile и маркетинга при разработке ПО - замечательно. Осталось привести хотя бы пару аргументов и примеров. Это помогло бы придать Вашим словам больше веса, хотя у нас тут всё очень неформально и дискуссия далека от научной.
На Ваше усмотрение.