Ивар Якобсон, почти легенда — основоположник UML, RUP, SEMAT — неугомонен, продолжает попытки навести порядок в индустрии разработки ПО. И на вопрос: «Что помогает оставаться таким активным» отвечает: «Having fun!» :)
Предлагаем читателю перевод интервью с Иваром, которое он дал в предверии своей осенней поездки в Санкт-Петербург организаторам конференции SECR.
Что вас вдохновило (и надеюсь, все еще вдохновляет), на создание и участие в создании RUP, UML, EssUP, EssWork, SEMAT?
Думаю, то, что я не выношу, когда люди тратят свою энергию, запал, работают день и ночь, делая при этом, простите, не очень умные вещи. И первое, что я изменил, когда был еще молод, в 1967 году. Я был руководителем проекта в команде разработки очень важной системы в Ericsson в Швеции. В то время мы разработали первую компьютеризированную телекоммуникационную систему переключения.
Я очень быстро понял, что существующий способ разработки софта несовершенен. У нас было одно большое хранилище программ и одно большое хранилище данных. Это было очень неэффективным подходом к построению системы, которую надо было все время менять. И я предложил то, что сегодня называют компонентной разработкой, которая подразумевает, что мы строим все системы при помощи взаимосвязанных компонентов.
Чтобы этот подход был принят, мне пришлось столкнуться с самым сильным за всю мою жизнь сопротивлением. Никто не хотел делать так. Программистам и их руководителям это не нравилось. Был только один человек, который одобрял предложенный подход к разработке ПО, но зато это был наш босс, и он решил реализовать задуманное. В результате мы получили самый большой коммерческий успех в истории Швеции. Даже успешнее, чем Volvo, ABBA и другие.
Вот так всё начиналось. Я не мог смотреть на то, как все эти замечательные люди работают неэффективно. И по этой же причине я неожиданно столкнулся со сценариями использования (use cases). Я не мог наблюдать, как неразумно мы работаем с требованиями. Позже я продолжил работать над RUP, а затем UML. За этим стояли схожие причины, которые привели меня к поиску общих методов и практик программирования. Я начал работать над тем, что стало OMG стандартом Essence 13 лет назад. На это у нас ушло 10 лет, однако сегодня я вижу успех.
По вашему мнению, какая главная проблема в разработке программного обеспечения на сегодняшний день?
Самая большая проблема в отсутствии общего понимания, что включает в себя разработка ПО. Мы плохо обучаем тому, как создавать коммерческий софт. Мы хороши в компьютерных науках, в развитии языков программирования, операционных систем и базовой технологии, но совершенно не умеем создавать коммерческие приложения. У нас много прекрасных компаний, разрабатывающих отличные продукты. Но продукты, это результат замечательных идей и замечательных людей, а не отточенной научной базы в разработке софта. У нас много хороших практик по разработке, особенно сейчас, в эпоху гибких методологий, но, в целом, они не базируются на какой-либо основательной теории, что позволяло бы постоянно совершенствовать их и прогнозировать результаты их применения.
Люди разрабатывают программное обеспечение по всему миру. К сожалению, в целом оно плохого качества, долго разработывается и слишком дорого. Мы, действительно, слишком долго занимаемся обучением людей, и трудно получить компетентных специалистов и т.д.
Суть в том, что у нас действительно нет общего понимания того, что такое разработка ПО или программная инженерия. И, по-моему, это является самой большой и самой серьезной проблемой сегодня. Люди, вместо того, чтобы повторно использовать знания, тратят много времени на то, чтобы делать вещи, которые являются не очень сложными или умными. Повторное использование знаний, повторное использование того, что требуется для разработки программного обеспечения, является самой недостающей вещью. И именно это является главным посылом сообщества SEMAT.
То есть SEMAT помогает решить эти проблемы?
Да, первым реальным результатом SEMAT был Essence в 2014 году. Essence является общей основой (common ground). Он описывает основные вещи, которые необходимо сделать, основные компетенции, необходимые для разработки любого современного программного обеспечения. Это «словарь», который также позволяет командам измерять прогресс и состояние проекта в процессе работы.
Эта общая основа в настоящее время используется в качестве платформы для описания многих различных практик: scrum, пользовательские истории [user stories], сценарии использования [use cases], непрерывная интеграция, микросервисы, облачные технологии и т. д. Essence включает в себя очень простой и интуитивно понятный язык для описания практик, с помощью которого их достаточно быстро и просто можно описать. Еще одно преимущество использования Essence: эти практики могут быть весьма эффективно скомпонованы в методики. Это очень умно, поскольку сегодня мы имеем сотни практик, которые могут быть скомпанованы в почти бесконечное количество методов.
Вернемся к вопросу о повторном использовании знаний. Раньше мы делали это плохо. Мы заимствовали идеи у людей, но у нас не было общей экосистемы, где мы могли бы использовать хорошо зарекомендовавшие себя, хорошо описанные, легко читаемые и применяемые методы. SEMAT решает эту проблему. В настоящее время мы создаем библиотеки практик, которые команды и организации могут использовать, выбирая нужные и комбинируя их для сбалансированной работы. Существуют инструменты, позволяющие людям делать это и улучшать практики, когда накапливается опыт. Мы получаем действительно многократное использование знаний!
Кто или что окзало на вас наибольшее влияние в жизни?
Несколько человек оказали огромное влияние на часть моей жизни, связанную с работой.
Мой первый руководитель в Ericsson, Ян-Эрик Нордин [Jan-Erik Nordin], в 1964 научил меня думать о дизайне на более абстрактном уровне, чем физический дизайн, на примере электромеханических систем (систем, построенных из реле, а не компьютеризированных). Я понял, как строятся системы из физических компонентов, и насколько важно определить взаимодействие [interfaces] между компонентами, так, чтобы потом можно было легко заменить компонент на лучший. Этот опыт я использовал позже в компонентах, полностью встроенных в софт.
Позже, в 1978 году, я встретил профессора Динеса Бьёрнера [Dines Bjørner] из Копенгагена. Он открыл мне глаза на значимость формальных методов, в частности того, как формально определить язык. Я использовал этот опыт в нашей работе над UML, а в последнее время — в языке Essence. Мы формально определили абстрактный синтаксис и статическую семантику, но чувствовали, что по практическим соображениям оперативную семантику нужно было делать определённо только на английском. С тех пор, как я понял ценность формальных методов, я применяю более точное ко всему, что делаю, и это помогает быть понятыми и оцененными среди экспертов.
Наконец, профессор Дейв Томас [Dave Thomas] из Карлтонского университета в Оттаве. Благодаря ему я стал одним из первых, внедривших в компании идеи гибких методологий. Это помогло мне переосмыслить работу над методами. Вместо того, чтобы пытаться сделать их окончательными, как мы делали с RUP, мы решили сосредоточиться на том, что было самым важным (менее 5%). Нам потребовался новый пользовательский опыт работы с методами, результатом чего стали карточки размером с игральные карты, представляющие практики — легкие для понимания и использования. В итоге мы хотели дать возможность командам самим легко выбирать собственные методы, и это привело к основам Essence и широко доступной библиотеке практик.
Что вы считаете своим главным вкладом?
Это сложно, кто-то другой, а не я должен сказать вам об этом. :)
Тем не менее, я размышлял об этом. Ericsson — большая компания, в 1967 году там работало несколько сотен программистов. Я много раз задавал себе вопросы: «Почему никто не придумал разработку на основе компонентов? Почему было так сложно убедить остальных в организации, что мы должны продвигать компонентное развитие? Что со мной не так, раз я боролся со всеми за то, во что верил, и почему я не сдался?». Если бы я сдался тогда, ничего бы не случилось в тот момент, — случилось бы потом, но не в то время. И ещё: «Почему мне пришли в голову сценарии использования, почему не кому-то другому? Почему мы разработали то, что стало самой популярной методологией 20 лет назад — RUP?» — и так далее. Трудно судить, но я думаю, что внедрение компонентного развития было, наверное, самым важным из того, что я сделал. Это привело к уверенности в себе и появлению новых идей.
Оглядываясь в прошлое, что бы вы изменили, если бы у вас был шанс?
Мне задали этот вопрос на очень большой конференции перед аудиторией примерно в 2000 человек. Кажется, это было в 1995 году на панельной дискуссии конференции OOPSLA в Штатах. В нашей группе было 5-6 человек, и почти все сказали, что ничего бы не стали менять. Но когда дело дошло до меня, то я сказал, что есть две вещи, которые я должен был бы сделать иначе, и на обе меня вдохновил мой друг Дейв Томас. Мы с Дейвом сидели в моем загородном доме, Дейв предложил: «Ты должен написать очень простую книгу, 150 страниц и только о use cases. Книга станет лидером на рынке, все захотят её прочесть». А я сказал: «Нет, нет, нет, нет. Разработка программного обеспечения — это слишком серьезно, чтобы уложить это в 150 страниц». Теперь, оглядываясь назад, я, конечно, следовал бы его совету.
Другая вещь, которую он предложил: «Позволь мне создать инструмент вместе с этой книгой. Я сделаю это за 100 тысяч». А я ответил: «Это слишком просто, тут же продвинутая инженерия, и инструмент тоже нужен продвинутый». Итак, я разработал инструмент, который стоил в первой версии около 1 миллиона долларов.
Вот эти две вещи, которые я сделал бы по-другому, показали мне, что я не понимал тогда маркетинга и пр. Так я ответил в 1997-м, и это мой ответ до сих пор.
Вы написали несколько книг, планируете ли вы выпустить новую? Если да, то о чем она?
Да, новая книга «Software Engineering Essentialized», есть пока в черновом варианте. Мы работали над ней вчетвером около двух лет, также создали проект с участием около 50 человек со всего мира, в том числе из России, для разработки учебных материалов и упражнений для книги. Cейчас эти специалисты проверяют её, и после обновлений на основе их комментариев книга будет опубликована. Она предназначена для студентов первых курсов — людей, которые никогда не разрабатывали какое-либо настоящее ПО, а написали только несколько небольших программ.
В прошлый раз на SECR вы говорили про «Agile и SEMAT — Perfect Partners». Каковы ваши планы на SECR 2017?
Мой доклад будет называться «Убейте методологии — высвободите практики». Я имею ввиду «брэндированные» методологии: в самом деле, нам не нужны чьи-либо «брэндированные» методологии, нам нужно создать собственный метод из тех практик, которые уже использовались неоднократно и хорошо зарекомендовали себя.
Помните ли вы самую первую конференцию SECR 2005? Если да, можете ли вы поделиться впечатлениями по сравнению с вашим последним посещением SECR 2013?
Я думаю, что первая конференция сильно отличалась от последней: тогда она была еще юной, доклады были не такими, как на других международных конференциях, они были более «академичными». В конференция в 2013 году была очень похожа на крупные конференции в США и Европе. На ней рассматривались темы практические. Она была больше для разработчиков и меньше для ученых по сравнению с 2005 годом.
Бывали ли Вы в Санкт-Петербурге?
Я много раз был в Санкт-Петербурге. Первый раз в 1961 году!
Значит, Вы видели, как изменился город.
Определенно. Во многих отношениях. Я учился в Технологическом институте Чалмерса, и после третьего курса мы отправились в студенческую поездку. Обычно эти поездки были в южную Европу, но в этом году мы отправились в Советский Союз. Во время поездки с нами всегда были агенты КГБ. Людей, с которыми мы встречались, позже допрашивали на тему того, что мы обсуждали. Нам это было очень любопытно, потому что мы не могли поверить, что подобное может произойти. Сегодня поездка в Санкт-Петербург — это как посещение любого другого большого города в Европе.
Вы так эффективно работаете в течение стольких лет. В чем ваш секрет?
Получать удовольствие! :)
Интервью: Анфиса Летучева.
Перевод: Юлия Крючкова, Анна Горбатенко (корректировки перевода категорически приветствуются :). Оригинал интервью: Interview with Ivar Jacobson.
Автор: juls
