Что такое сю-ха-ри и при чём тут Agile

Несколько человек из пришедших на курс оказались ярыми противниками любых стандартов, методик и лучших практик. Причем подавали своё неприятие под соусом «я – практик с более чем десятилетним опытом».

Написать эти заметки меня подтолкнули три обстоятельства.

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

И, как вы понимаете, несколько занятий посвящаю Agile. Мало того, выяснилось, что Agile, в частности, Скрам, очень хорошо ложится на процесс обучения, когда практические занятия проходят через равные промежутки времени. Действительно, заставлять студентов разрабатывать документы, из которых непонятно что, с учетом их небольшого опыта, может вырасти к концу семестра, просто негуманно. А Скрам диктует показ прототипа продукта – результата Спринта каждое занятие. И занятия происходят каждую неделю/две недели/ месяц, прямо по Agile Manifesto.

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

Однако студенты, да и не только они, к сожалению, обычно рассматривают Agile как альтернативу классическому водопаду. К этому несомненно толкает известное противопоставление:

·       Люди и взаимодействие важнее, чем процессы и инструменты

·       Работающее программное обеспечение важнее, чем исчерпывающая документация

·       Взаимодействие с заказчиком важнее, чем обсуждение контракта.

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

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

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

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

Второе. Проведение курса по Управлению ИТ для ИТ-директоров

И именно это второе мероприятие послужило спусковым крючком для того, чтобы захотеть высказаться на страницах журнала. Несколько человек из пришедших на курс оказались ярыми противниками любых стандартов, методик и лучших практик. Причем подавали своё неприятие под соусом «я – практик с более чем десятилетним опытом». Мои возражения, что все стандарты и методики разрабатывают как раз практики, отвергались на корню.

Путём долгого, почти детективного расследования удалось выяснить: все дело в том, что обучающиеся построили совершенно уникальную систему понятий, не соответствующую ни международной, ни отечественной практике. И их многолетняя практика эту систему понятий только закрепила. Например, если все процессы ITIL реализовать в сервис-деске, то можно сказать, что весь остальной ITIL как бы совсем не нужен. Но мне кажется, что для такого заключения надо, как минимум, ITIL изучить. А он, как любая зрелая методика, основывается на соответствующем словаре.

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

Третье. Японская модель Сю-Ха-Ри

На просторах Интернета мне попалось описание японской модели Сю-Ха-Ри, определяющей принципы обучения:

•       Сю - следуй правилам, чтобы изучить основы, 

•       Ха - изучай обстановку и, если надо, нарушай правила, 

•       Ри - ищи собственный путь.

После посещения в 2008 г. Японии с делегацией Российского Союза ИТ-директоров я прониклась глубоким почтением к японской культуре. Уважительное отношение к себе и другим оказалось чрезвычайно привлекательным. Да и результаты, которых добилось японское общество, впечатляют. Поэтому на Сю-Ха-Ри стоит обратить внимание.

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

А если вы не знаете японского и вам трудно запомнить название принципа, то читайте его просто как су-ха-ри.

Читайте также
Круглый стол «Цифровая деградация», организованный в рамках форума «ИТ Диалог 2024» стал местом честного разговора о том, как выживать в мире, где взломы — это вопрос времени. Участники обсуждали, что важнее: безопасность или удобство, когда стоит заменять иностранные решения на российские, а когда лучше подождать, и кто в итоге отвечает, если что-то пошло не так. Были примеры из реальной жизни, споры о том, кто должен делить ответственность, и даже немного философии. Вопросов оказалось больше, чем ответов, но одно ясно точно: безопасникам приходится лавировать между сложными решениями и высокой ответственностью каждый день.

 

 

Читайте также
Готова ли Россия к массовому внедрению ИИ, какими ресурсами для этого располагает, каких не хватает? Какой помощи рынок ждет от государства, объединят ли Сбер и «Яндекс» вычислительные мощности как будет развиваться инфраструктура для ИИ и чего ждать от экономики данных — обо всем спикеры ведущих участников рынка говорили на круглом столе IT-World.

Опубликовано 12.11.2020

Другие публикации эксперта