Один из самых популярных вопросов у интересующихся: «Когда этот ваш Agile применять можно, а когда нет?»
Можно ли применять Agile в управлении бухгалтерским отделом? В юридической компании? Работает ли Agile в банках или в строительстве?
Agile это множество различных методик, объединённых одними и теми же принципами, описанными в манифесте.
Если посмотреть на эти принципы, становится ясно, что изначально Agile появился в разработке программного обеспечения. Это так. Но с тех пор Agile далеко вышел за пределы IT. Тем не менее, исходя из этих принципов, можно и определить границу применимости Agile. Рассмотрим некоторые их них.
Да, на каждом шагу! Продукты постоянно эволюционируют, взгляд заказчика на них тоже. Значит, судя пока только по этому одному принципу, методика, берущая за основу нормальность изменений, в программировании применима.
А вот, тоже! Те, кто близок к проектированию, знают, что при проектировании очень часто меняются требования, в связи с уточнением данных об объекте. Так что этот принцип в методике, очевидно, применим и к проектированию.
Тут скорее нет. Изменение требований к бухгалтерии — это очень редкое событие. Меняют налоговое законодательство редко. Так что вероятно этот принцип Agile в бухгалтерии не слишком нужен.
А вот тут очень даже важен. Консультирование — это каждый раз индивидуальный проект, а не повторяющийся процесс. Хоть речь о тех же финансах, но у заказчика, по мере понимания ситуации в компании, требования к результатам проекта вполне могут меняться. Сначала думали о том, как оптимизировать налоги в России, а потом вообще об оффшоре речь зашла.
Поначалу этот принцип кажется не применимым ко многим областям. Ну как, например, может крупный девелопер постоянно работать с каким-то небольшим проектным бюро? Но давайте на стадии оценки применимости Agile подумаем пока не о физической возможности реализации этого принцип (скажу пока только, что это возможно), а о том: «если бы получилось его применить — была бы польза?». Попробуем:
Очевидно, что да. Если бы по каждому вопросу можно было бы оперативно получить мнение заказчика, всё решалось бы быстрее.
Тоже да.
Пока речь касается налогового учёта — вряд ли полезный принцип. От того, что у бухгалтера будет прямой контакт с заказчиком налогового учёта (а кто это, кстати, государство или директор компании?) — сильно работа не поменяется. Другое, конечно, дело — управленческий учёт — там ого-го как нужен контакт с управляющим.
Не буду рассматривать остальные принципы, ибо всё это давно уже сделано, я лишь хотел проиллюстрировать откуда вытекают ограничения применимости Agile. Сразу покажу результаты:
Внедрение Agile оправдано, если соблюдаются следующие условия:
Здесь подходим к хорошему вопросу терминологии.
Agile — пошёл от IT. Но в то же время на заводах Toyota задолго до Agile использовали другой подход. Не вдаваясь в исторический экскурс о TPS и Lean, обобщённо называем его Lean — бережливое производство. Оно же «бережливая разработка» или «бережливое проектирование» итп.
В свою очередь принципы Lean:
Я не буду на них сейчас останавливаться и разбирать так же, как принципы Agile. Это не цель данной статьи. Перейдём сразу к выводам.
Нет, весь этот экскурс нужен был чтобы объяснить: иногда то, что называют Agile ближе по своей идеологии к Lean.
Из зарубежного источника очень правильная картинка:
Видно, что множества Agile и Lean пересекаются.
По сути, процесс, внедряемый в конкретной компании, может брать часть своих особенностей из Lean, часть из Agile. Именно это я делал, когда внедрял Agile в строительной компании, и когда ставил процесс по разработке сценариев игр в своей компании Questoria.
Применимость или не применимость Agile и Lean в компании зависит не от слов "внедряем Agile" или "внедряем Lean", а от конкретного перечня практик Agile или Lean, которые внедряются в данной компании.
И та и другая группа методик содержит определённые установки, цель которых трансформировать культуру компании.
Например, в одна из таких установок в Lean: «ожидания — это ВСЕГДА зло». ВСЕГДА.
Любыми способами устраняем ожидания. Отправили документ на «согласование» и взялись за другую работу, и «ждёте» его согласования несколько дней? Плохо! По Lean так не делают. Надо заняться согласованием лично — ускорить его. Не должно быть потерянного времени на ожиданиях и заниматься в это время другой работой — это не «эффективность», а прятание проблемы с долгим согласованиями под ковёр.
В Agile одна из установок «поговорив о задаче, можно сэкономить кучу времени на её решении».
Начал делать что-то и считаешь, что сам знаешь как лучше? А вот нет — всё равно поговори с коллегами. И неожиданно коллега, который совершенно не разбирается в твоей области, вдруг подкинет свежую мысль и ты поймёшь, что эту задачу можно сделать вполовину проще, если в другом отделе сделают одно нововведение.
Когда такие установки входят в культуру компании и в кровь сотрудников: «ожидание — всегда зло», «общение по задаче всегда ценность», тогда мы и говорим о внедрении Agile или Lean.
Как вы увидели Agile и Lean — просто набор принципов. А вот конкретное их применение называется процеcсом управления (или разработки). По принципам Agile или по принципам Lean построены десятки разных систем: Scrum, Kanban, TPS, XP, Scrumban и прочим. То есть:
Внедрение Agile или Lean — это внедрение установок и процесса, позволяющего выявлять проблемы и решать их в соответствии с установками.
То есть прежде, чем говорить, подойдёт или нет Agile вашей компании нужно понимать, что Agile и Lean огромны — и какая-то часть ТОЧНО очень хорошо ляжет на процессы вашей компании и поможет вам сделать их лучше. Но не стоит хвататься за первый услышанный процесс. Подумайте какой подойдёт лучше. Или спросите меня