Спикер о вебинаре:
Эта работа посвящена вопросу применения прикладных методов, которые должны упростить достаточно сложную область управления ИТ проектам. В вопросах применения прикладных методов, необходимо, чтобы описываемая область получила строгую модель описания на которую можно опираться, для чего предлагается использовать процессы разработки и Essence в качестве одновременно и языка их описания и онтологической модели проекта. Использование Essence как модели описания позволяет получить достаточно строгую модель проекта, к которой применимы прикладные методы. В качестве proof-concept применяются динамические байесовские сети, и решается задача поиска ложнопозитивных ошибок менеджера в Essence Alpha Poker.
Видео: https://youtu.be/paM0cYlI-Ag
Презентация: https://drive.google.com/file/d/1Z29mNQe6syReRNq0htLPY_vGO2kJM2Zi/view?usp=sharing
Cсылка на статью: https://www.researchgate.net/publication/338037221_Implementation_of_Essence_Practice_into_Project_Management_System_Redmine
(00:00:00) (Начало записи)
Николай Михайловский: Добрый день, коллеги. Я Николай Михайловский, генеральный директор компании «НТР», и я приветствую вас на очередном научно-техническом вебинаре, который «НТР» проводит вместе с Высшей IT-школой Томского государственного университета. У нас сегодня Денис Змеев с рассказом про концепцию интеллектуального помощника для менеджера IT-проектов. Это не совсем про нейронные сети, это больше про менеджмент проекта и то, что вокруг него, но и не без интеллектуальных сетей тоже.
Денис, пожалуйста, вам слово.
Денис Змеев: Добрый день/вечер всем, в зависимости от часового пояса. Этот доклад – фактически это результат 5-6-летней работы, которую я вел в своей аспирантуре, начиная с магистратуры, фактически к вопросам, связанным именно с более разумным, правильным и эффективным управлением проектами в программной инженерии на основе процессов разработки.
Сразу оговорюсь, что если мы говорим про практическое применение любого метода, интеллектуального, не интеллектуального, прикладного, не прикладного, то всегда есть такая простая схема. У нас есть что-то в реальном мире типа текущего состояния проекта. Мы преобразовываем его в какую-то математическую модель, это отдельная задача, которую нужно сделать хорошо, качественно. Дальше мы на уровне этой самой модели делаем какую-то прикладную математику, алгоритмику и так далее, получаем вторую модель. После этого на основании второй модели пытаемся сделать какой-то прогноз развития снова в реальный мир, а потом фактически показываем, условно, нашему заказчику или интересанту в стилистике то, что мы получили, оно похоже на правду, непохоже на правду. Если он говорит, что «похоже на правду, могу это использовать», значит, все сошлось, все работает. Если нет – не работает.
Следовательно, если я попытаюсь очертить логику, что должен делать интеллектуальный помощник, он фактически должен брать на себя задачи, начиная от преобразования ситуации реального мира до какого-то формального «прогноза» того, что в реальном мире должно случиться. Прогноз в кавычках, потому что это может необязательно прогноз, это может быть и просто вспомогательная полезная информация, которой до этого не было видно.
Теперь, имея эту схему в голове, давайте рассмотрим, что происходит в отрасли управления проектами и в программной инженерии в частности. В целом, если рассматривать модель, математически объект реального мира как в проектной разработке, то существует просто множество, возможно, даже очень большое множество работ, которые в качестве математической модели берут то, что называется сетевые графики проекта. Наиболее известный их пример – то, что называется диаграммами Ганта. С ними получается вообще все замечательно, то бишь включая условно работы, которые доходят до того, как решить задачу назначения или какой метод решает задачу назначения точнее, даже при условии того, что некоторые, условно, работы и так далее могут быть выполнены не со стопроцентной вероятностью и так далее. В общем, здесь работает все замечательно, хорошо.
Но у сетевого графика проекта, если вы попытаетесь применить его к IT-отрасли, есть несколько печальных особенностей, которые вкратце можно выразить. Их разработка экономически нецелесообразна в большинстве случаев, когда мы говорим про проектную разработку. Поскольку сетевой график проекта нужен в первую очередь для планирования, а все методы оптимизации какие-то могут упрощать некоторые спорные пункты или проблемы, связанные с планированием работы, то зачастую потеря, условно, одной-двух итераций, это могут быть месяцы разработки, может обойтись дешевле, чем разработка и поддержание потом в состоянии календарного плана-графика проекта в том или ином виде. А если мы к этому добавляем еще проблему того, что требования могут поменяться, всплывают неизвестные условия и так далее, после которых план-график проекта нужно перестраивать, соответственно, затраты на него будет расти просто пропорционально дороже. В результате получаем, что красивая, клевая математическая модель на практике малоприменима.
Давайте рассмотрим другой набор методов, которые зачастую не требуют, условно, красивую, строгую формальную модель, которые могут работать уже постфактум, по существу, с данными. Зачастую к этому относится ___ (00:04:15) прикладной статистики. Если мы говорим про эту отрасль, то в 1996 году вышел страшный, печальный сборник, который, мягко говоря, сказал, что это почти что нерешаемая задача. На слайде, в принципе, основные причины, почему она нерешаема. Это фактически анализ разных кейсов компаний, которые проходили в Америке, от крупных кейсов типа разработки системы для запуска ракет для НАСА до кейсов автоматизации банковских систем. Разные команды, которые пытались применять разные математически подходы для разных целей. Одна из команд пыталась относиться к программной инженерии как к инженерии, получила, что природа нашей работы, программных инженеров, неинженерная, то бишь у нас нет абсолютно четкого прогресса по разработке конкретного одного изделия.
(00:05:04)
В этом плане все, что работало до этого, внезапно не работает. При этом эта же команда дальше утверждает, что при этом технологический прогресс есть, и он при этом достаточно специфичный, но при этом не абсолютно строго формальный. В результате статистика, которая работала бы к общему управлению проектами, тоже начинает сбоить и выдавать некоторые огрехи и противоречивые результаты.
Команда, которая разрабатывала как раз банковские системы. пытался анализировать программную инженерию с точки зрения характеристики изделия. В нашем случае они пытались анализировать строчки программного кода. С этим у них тоже, естественно, много что не получилось, потому что сложность программного изделия не измеряется строками кода, а все другие характеристики типа производительности, совместимости и прочие другие способы охарактеризовать то, что мы получаем в результате, несильно помогают оценить сложность разработки или спрогнозировать работы.
Дальше, еще одна команда анализировала, как непосредственно работают разработчики и пыталась их ставить, условно, в абсолютно тепличные жесткие условия, при которых фиксировались буквально до дыхания и температуры в комнате. Внезапно они поняли, что фактически, когда мы говорим про программную инженерию, у нас нет объективных факторов анализа, что происходит с разработчиками, потому что у нас нет, условно, затрачиваемых ресурсов, у нас нет простоя, условно, приборов или личного конвейера, или чего-то такого, что позволяло бы оценить работу разработчиков, кроме как непосредственно спросить разработчиков.
Когда мы начинаем их спрашивать, то это либо субъективные данные, либо фактически любые попытки навязать анализ и наблюдение за разработчиками другие методами сталкиваются с тем, что это начинает влиять на результат.
В результате получается, что красивая абстрактная математическая модель неприменима на практике, модели, которые спокойно работали бы без нее, неприменимы на практике, потому что специфика нашей отрасли весьма специфична и с ней сложно что-либо сделать по-другому. А фактически многие попытки сделать что-то другое, то бишь разработать другие математические модели, требуют новую модель объекта, которая до этого в программной инженерии фактически что… до сих пор сложно сказать, что она есть.
А после того, как эта модель будет получена, если мы говорим про модели, связанные с машинным обучением и статистикой, еще и нужны размеченные согласно этой модели данные, которые мы должны брать, по логике вещей, из профессионального сообщества, поскольку в первую очередь профессиональное сообщество заинтересовано в эффективных управления. Но удача найти у них датасет при условии того, что еще матмодели даже нету.
Фактически дальше возникает вопрос, а где найти основу для матмодели, которая позволит что-то применить или исправить в этой отрасли. В процессе наших изысканий мы подумали, что существуют так называемые процессы разработки, которые все знают как SCRUM, Agile, водопад, унифицированный процесс, куча разных видов driven development и прочего, прочего, прочего. По своей природе и семантике того, что в них написано, они, так или иначе, пытаются нарисовать модель проекта. Но модель проекта, которая постепенно начинает преобразовывать среду управления, из которой в будущем можно забирать данные, а среда управления проектами позволяет нам фиксировать проектную деятельность, и вроде бы все замечательно. Вот основа новой модели, берем, изучаем процессы разработки как модель, и пытаемся на основании ее что-нибудь придумать.
Но тут тоже возникает проблема, что процессы разработки как целый класс сущностей придумываются в первую очередь бизнесом для решения принципиальных прикладных задач. Основная особенность проблемы того, что она придумана бизнесом, то, что до сих пор у процессов разработки нет общепринятого определения, что это такое на самом деле. Существует термин «процессы разработки», существует методология разработки, существует метод разработки. В зависимости от того, какую литературу вы читаете, какого автора, вы найдете абсолютно разные определения, которые иногда расходятся, противоречат и называют одну и ту же вещь абсолютно по-разному.
Дальше, учитывая, что это было решение профессионального сообщества, это превратилось еще и в бизнес по придумыванию и продвижению процессов разработки. К сожалению, специфика такая, что люди, которые в этом бизнесе стали принимать активное участие, стали дистанцироваться друг от друга, создавая новый набор терминологии, пытаясь специализированно говорить, что наши сущности не такие, как они были до этого, а многие даже не пытались думать на тему формальных и неформальных внутренних структур собственно процесса разработки, и сводились по принципу «оно так работает, делайте вот так, и все будет хорошо».
При этом же, как ни странно, тому же классу процессов и разработки свойственна проблема в том, что они позволяют модифицироваться, и иногда на конференциях можно заметить интересную ситуацию, при которой рассказывают о своем опыте два скрам-мастера из разных проектов, когда они начинают интересоваться, чем непосредственно занимается другой собеседник, внезапно выясняется, что роль скрам-мастера еще при этом принципиально различается. При этом, казалось бы, они все последователи SCRUM.
(00:09:59)
Последний фактор, который во все это ввел еще просто некоторую долю хаоса и безумия, что фактически эта отрасль превратилась одновременно и в хайповую, и модную, еще и случился «парадокс выжившего», где можно пытаться прогнозировать некоторые вещи, связанные с кризисом доткомов, которые фактически привели к тому, что очень многие Agile based методы стали популярными, потому что случилось много стартапов, которые пережили кризис доткомов. При этом, благодаря или вопреки Agile они пережили, естественно, история умалчивает, но при этом то, что сейчас Agile перешел во все отрасли, кроме как айтишной, это вещь, которую мы вполне себе наблюдаем в выступлениях даже, условно, генерального директора «Сбербанка».
Так вот, чтобы со всеми этими, мягко говоря, безобразиями бороться, создалось сообщество Senate, которое придумало язык Essence. Язык Essence – фактически это язык, который пытается навести порядок, иными словами, это язык описания процессов разработки, это его немножко упрощенная интерпретация. Основная принципиальная особенность этого языка, помимо того, что графическая нотация, ставшая стандартом MG Group и прочие-прочие вещи, было то, что, в отличие от предыдущих попыток типа (00:11:10) они сказали, что вообще-то все процессы разработки состоят из так называемых практик, то бишь какие-то вещи, которые процесса разработки стараются делать одним и тем же или схожим образом. Фактически процессы разработки, как бы вы их ни комбинировали, не адаптировали под свои собственные компании, проекты и так далее, зачастую сводятся к тому, что вы набираете набор практик, которые вас устраивают, остальные либо выбрасываете, либо меняете, либо не делаете это практиками, просто-напросто как получится. Благодаря этому как-то пытаются навести порядок между тем, что творится в компании, в ___ (00:11:45) ___ сообществе, в отрасли менеджеров проектов, которые в эту штуковину пытаются лезть и разобраться, и в академическом сообществе.
Дальше будет небольшой обзор элементов языка, которые достаточно критичны, но если вы в курсе, то можете дальше немножко упустить внимание, и все будет нормально. Одним из интересных элементов, которые ввели авторы Essence, они ввели такую сущность, которая называется ALPHa. Это акроним от интересного термина, который фактически сводится к тому, что абстрактный уровень прогресса, иногда в некоторых старых источниках они называли это абстрактным уровнем здоровья проекта, а не прогресса. Но фактически это штуковина, которая опять же на абстрактном уровне фиксирует, как хорошо, плохо, далеко вы продвинулись в какой-то определенной отрасли. Согласно авторами Essence, в любом проекте по разработке программного обеспечения существует семь основных «альф», они перечислены на слайде.
Особенность «альф» заключается в том, что помимо того, что они это дело фиксируют, фиксируют они это фактически при помощи двух механизмов. Механизм первый. У каждой «альфы» есть свой собственный набор состояний, который хоть как-то позволяет оценивать, на каком этапе вы находитесь. К скрину, который сегодня прикладывался в качестве приглашения об этом семинаре, показывались как раз карточки состояния «альф» с циферками и с указаниями, что это означает.
Каждое состояние, второй механизм состоит из набора чекбоксов, утверждений, которые достаточно легко проверяются по принципу «да/нет», по крайней мере, выглядит, как они проверяются, легко, но которые позволяют понять, «альфа» находится или не находится в этом состоянии.
Дальше фактические вещи, которые больше похоже на то, что происходит на обычной практике, это Activity Space Activity, которые в этом плане можно свести, что Activity очень сильно выполняет функции и задачи классических тасков и задач в проектах, Activity Space – это некоторая общая абстрактная классификация этих самых задач. Если мы говорим, что нужно провести встречу с заказчиком, узнать у него требования, это конкретно будет Activity, но при этом это все делается в рамках появления требований, которые относятся к Activity Space.
Последние два элемента, которые мы рассмотрим, это рабочий продукт, фактически сущность, которая максимально близка к понятию артефакта в программной инженерии, и компетенция, которую ввели разработчики Essence, нужна для того, чтобы описывать, условно, для практик, а какие люди потенциально могут этих практики выполнять. Компетенции при этом не совсем напоминают роли, но они будут немножко в стороне фактически дальше.
Помимо элементов языка, также авторы Essence создавали ядро, которое позволяет нам описывать общую структуру проекта, особенности, в частности, как взаимодействуют элементы друг с другом, и как работают элементы, которые фактически ввели авторы Essence, которые называются «альфами», как они взаимодействуют, на что они влияют, на что они должны смотреть и с чем что фактически будет связано. С такой логикой фактически каждая «альфа» фиксирует какую-то свою определенную зону проекта, при этом эти зоны тоже, как вы видите, разделяется на три внутренних подуровня в зависимости от того, к какой отрасли эта зона проекта относится.
(00:14:56)
У каждый «альфы» есть состояние. Артефакты в первую очередь подтверждают, что «альфы» этих состояний достигают, а Activity созданы для того чтобы создавать, обновлять и развивать артефакты дальше, в зависимости от того, что у вас происходит в проекте.
К этому, соответственно, добавляется, что помимо общих структур и общих состояний, соответственно, существует полный список всех состояний со всеми утверждениями, которые там есть, и даже существует игра, созданная для обучения и для некоторых поисков ошибок в компании, которая называется ALPHa State Poker, которая фактически создана на основании того, что команда начинает анализировать и рефлексировать свой прогресс при помощи как раз состояния ALPHa-карточек.
Все вот эти вот вещи, описания в стандарте, дополнительные анализы, связи и прочее, прочее, прочее позволяют, так или иначе, выразить то, что мы назвали теоретическим контуром Essence. Фактически это уровень ядра, которое позволяет описывать высокоуровнево, абстрактно прогресс проекта, и благодаря которому в идеале описываемые практики в реальных проектах должны сходиться. Тут пока еще вопрос, как, четко или нечетко они сходятся, потому что там возникла парочка интересных моментов в разговоре с авторами Essence, но, тем не менее.
В теории фактически то, что вы видите сейчас, это фактически все «альфы», семь основных «альф» со всеми состояниями и с пространствами активности, которые показывают переходы между состояниями в разных «альфах», и как они связаны друг с другом. При этом же, обладая потрясающими возможностями описывать теоретический, абстрактный уровень, который так любит академическое сообщество, также Essence позволяет описывать конкретные практики, которые используются в разных компаниях, в разных процессах разработки, в разных проектах даже в одних и тех же компаниях. При этом это описание всех практик на уровне, какие конкретно получаются таски, какие эти таски должны проходить артефакты, как эти артефакты будут меняться, с какими «альфами» это все связано, также все спокойно описывается, вписывается, и можно использовать, причем достаточно легко модифицируемо, потому что в целом есть хорошая графическая нотация, которая в целом понятна. В этом плане эта вещь позволяет как легко описывать и легко решать задачи обучения новым практикам и изучению, что там происходит, так и, соответственно, некоторое общее детальное формальное описание всего процесса разработки, или то, что называется в Essence методом разработки, для того чтобы это дело как-то в будущем анализировать.
В целом все хорошо, замечательно, потрясающий язык. Существуют даже тулзы, которые его поддерживают, чтобы эти вещи описывать. Тут на слайде два скрина, один из свободной ___, (00:17:44) где описаны три метода разработки, Agile, Essential с Agile Scale и Unified Process, а справа внизу скрин из ___ (00:18:01) средства для фактически создания подобного рода описаний.
Но проблема в другом, что, создав такой язык, создав некоторую идеологию, которая посвящена тому, что нужно охотиться за практиками и из них компоновать процессы разработки, сообщество и компания Ivar Jacobson International не решила другую задачу, пока не решила, но они уже пытаются – как после этого, имея красивую формальную, даже строгую в какой-то степени модель процесса разработки, преобразовать среду управления проектами так, чтобы теперь среды поддерживали правила процесса разработки автоматически, без необходимости это придумывать менеджерам проекта.
Это была одна из частей моей условной исследовательской прикладной разработки. Фактически в процессе нее мы были вынуждены придумывать более упрощенную модель из Essence, потому что некоторые вещи оказались слишком, избыточно семантические и большой роли с точки зрения формальной структуры не играли. Дальше, соответственно, когда мы придумали промежуточную модель, мы придумали и как фактически ее в случае чего адаптировать под разные среды управления проектами, создав модели описания, и как после этого конкретно в этой среде управление проектами можно фактически использовать некоторые фишки Essence, чтобы они выполнялись автоматически без необходимости это делать, опять же поддерживать менеджеру ручками.
В процессе все это дело, описание модели, выполнение, логика должна приводить к тому, что вы можете поддерживать, перестраивать практики, использовать разные практики, которые описаны в Essence, в своих проектах. При этом от вас это просто потребует минимум времени на настройку и на конфигурацию.
Как я сказал, это было сделано. В целом у нас две среды управления проектами, которые, так иначе, получили такое решение, одна из них – это Redmine, фактически два скрина, одно – это импорт практики, второе – это конкретное выполнение таска, при котором вы указываете, с какими артефактами этот таск был связан.
(00:19:58)
Если вы ставите таск, вы можете указать, к какому архетипу активности он указался, и в зависимости от этого вам просто укажут, с какими артефактами он должен быть связан, и тогда при завершении этого таска эти артефакты тут же переведутся в нужный уровень детализации, который у них должен быть указан. Казалось бы, все, то бишь, вот решена в каком-то формате задача, как фактически процессы разработки, описанные формально, конвертировать в среду управления проектами. У нас теперь есть формальная модель, из которой дальше потенциально можно делать, как минимум формальная модель реального объекта у нас существует.
Однако дальше возникает вопрос – о’кей, формальную модель мы получили, давайте думать, что мы будем делать с тем, какой метод должен разрабатываться. В попытках анализа и поиска методов внезапно немножко страшные и убивающие все пространство идеологии выводы.
Проблема первая. Если я возьму в качестве основы формальной модели процесс управления, который называется Rational Unified Process, то фактически ни к одной другой компании, кроме как работающей по Rational Unified Process, этот метод применим не будет. Следовательно, я должен подобрать какой-то метод, который не накладывает жестких ограничений на то, каким способом именно компания занимается разработкой.
Второе. При этом, да, мы должны учитывать специфику при разработке, чтобы это не превратилось просто в абстрактный метод управления проектами, который вообще никак не связан с программистской деятельностью.
Третья проблема опять же связана с тем, что, поскольку предыдущие попытки академического сообщества красиво и идеально решить задачу для профессионального сообщества в вопросе как лучше управлять проектами, проваливались, то фактически сейчас все подобного рода заявления, попытки, призывы к тому, что «давайте проведем эксперименты» и так далее, скорее всего, будут проигнорированы, поскольку это убытки, которые не приносят прибыли. Соответственно, нужно найти какой-то метод, который позволит хотя бы показать, что прибыль можно хоть какую-то получить, или хоть какую-то выгоду для компании получить, при этом не требуя от компании многих затрат на изначальное внедрение и попытку эту выгоду получить.
Но при этом как только метод будет запущен, дальше возникает вопрос: о’кей, данные теперь появились, теперь давайте думать, как этот метод улучшить. Соответственно, как я сказал про прибыли и убытки, поддержание этого метода, не говорим про развертывание и внедрение, тоже не должно быть накладным, потому что иначе, соответственно, для компании это убытки, отрыв от работы и прочее, следовательно, это потеря времени и ресурсов, которые дорогие.
В поисках, в изысканиях и так далее случайно выбор пал на то, что называется динамическая байесовская сеть. Если быть более строгим, то, что я дальше буду рассказывать, это очень оригинальная модификация и другой способ применения алгоритма байесовского отслеживания знаний для случая с несколькими навыками, которые иногда можно загулить как в английской аббревиатуре BKT, если вы в курсе, что это такое и как оно работает.
Если вы не в курсе, то в целом работает оно примерно вот так. Соответственно, у нас есть утверждения, о которых я говорил раньше, из которых определяется состояние проекта, состояние ALPHa-карточек, из которых можно отслеживать некоторый общий прогресс проекта. Идея байесовских сетей – фактически это частный случай цепей Маркова, в которых есть скрытые и явные узлы, и наблюдаемые узлы. Фактически мы можем спросить менеджера, что он считает о каком-то утверждении в его проекте, и для нас это будет наблюдаемый узел, то бишь мы всегда можем спросить «что ты считаешь?» и получить ответ, 0 или 1, поставлен чекбокс, не поставлен чекбокс. При этом существует какое-то аморфное состояние, что происходит с проектом на самом деле. Одна из особенностей программной инженерии в том, что это экспертная работа, означает, что эксперт может ошибаться, при этом зачастую ошибки экспертов в IT-отрасли это бо́льшая часть причин, почему проекты проваливаются.
Соответственно, есть вероятности, при которых то, что менеджер сказал, является правдой гарантированно, или то, что менеджер мог ошибиться. Причем мы знаем, существует категория ошибки, и ложноположительные, и ложноотрицательные, то бишь менеджер может просто не знать, что в его проекте на самом деле эта штуковина уже была выполнена, или то, что на самом деле он этой штуковиной уже обладает, но при этом он боится, что он неправ, поэтому он говорит, что нет.
Соответственно, если мы дальше эту штуковину введем, то, поскольку состояния проекта семантически связаны друг с другом, то бишь то, чтобы вы работаете со стейкхолдером, вам условно позволяет оценивать вашу потенциально будущую ролевую модель в проекте, то состояние проекта в разных чекбоксах начинает последовательно влиять друг на друга в разных ипостасях, и причем меняться по итерациям.
(00:24:54)
Если мы только начинаем проект, скорее всего, у нас все будет поставлено как «нет», как только прошла итерация, какие-то работы мы уже выполнили, там пошел прогресс. Эти состояния нам позволяют, соответственно, оценивать далее не только мнение менеджера об этом пункте, но так же остальные утверждения, связанные с этим состоянием.
Если эту концепцию развивать дальше, то получается в среднем такая вещь, что если команда будет играть в Essence ALPHa Poker, что в среднем занимает 15-30 минут в неделю, то, прогоняя мнение команды через построенную байесовскую сеть, можно получить пункты, в которых команда потенциально ошибается. В нашем случае ложно-положительно ошибается, потому что ложноотрицательные ошибки вполне себе допустимы с точки зрения семантики и управления проектами. Если мы говорим про общую достигнутую выгоду, у человека, у которого обычно много вещей, которые нужно контролировать, появляется возможность смотреть на какие-то вещи объективно, то бишь из того, что он, может быть, не знает, не помнит, не контролирует, не учитывает, что вроде бы, как мне, по крайней мере, кажется, вполне себе разумная, допустимая вещь.
Это как выглядит теория, как это итого реализовано и во что эта штуковина превращается. У нас есть утверждения, которые были на ALPHa-карточках. Каждое утверждение итого конвертируется в 3 различных вершины байесовской сети. Это скрытое значение этого самого утверждения, влияние предыдущей итерации проекта и мнение менеджера об этом утверждении.
На слайде приведен пример для утверждения, то, что мы договорились о выборе критериев архитектуры для «альфы» «Программные системы», состояние –архитектура была выбрана.
Затем все эти утверждения, соответственно, выносятся на общий уровень и появляются отдельные узлы, которые описывают общее состояние ALPHa-карточек непосредственно этой «альфы». Соответственно, сейчас на слайде вы видите ALPHa байесовской сети, которая связана непосредственно только с программной системой.
Что происходит после этого? После этого мы начинаем оценивать зависимость между разными утверждениями с разных ALPHa-карточек, как они семантически и еще и стандартно влияют друг на друга, таким образом, добавляя дополнительные зависимости между утверждениями, которые есть о проекте. Соответственно, к сожалению, сам стандарт несильно эти утверждения фиксирует. У него есть некоторое общее описание, которое обычно сводится к тому, что для этой категории деятельности это состояние, в целом другая «альфа» должна быть в этом состоянии, но при этом без указания на конкретное утверждение, которое конкретно есть в чекбоксах. Поэтому остальные связи пришлось фактически экспертно восстанавливать, анализируя семантически и буквально до формулировок, иногда вплоть до некоторых терминов, что же на самом деле здесь написано.
Справа на слайде видно непосредственно, как мы это делали, это пример одной из карточек конкретного одного утверждения одной из «альф», слева – некоторая общая концепция, во что эта штуковина превращается. Прогнав это все через все 204 утверждения, через все тридцать с лишним состояний проектов, мы получаем вот такую байесовскую сеть, в которой 646 вершин, больше 1800 связей. Другая особенность такого подхода к этому анализу в том, что каждая вершина, имеющая количество входных ребер m, генерирует вероятностные векторы из количества элементов 2m+1. У самой большой вершины с самым большим число входных ребер у нас число примерно было 14, если память не изменяет, нужно потом перепроверить.
Дальше мы это все должны превратить в способ подсчитать вероятности, непосредственно которые следуют из байесовской сети для каждого утверждения в отдельности. Для этого можно воспользоваться достаточно своеобразным очень простым алгоритмом. Фактически на слайде приведен пример, как непосредственно в системе, в которой мы делали эту самую сеть, контролируются все связи, указываются все вероятности, которые там прописаны. После этого мы определяем, что непосредственно менеджер думает об этом состоянии, оно истинно или ложно, и из этого определяем ту часть сектора, которая нас интересует, а потом просто-напросто используем формулу полной вероятности от всех зависимых вершин, которые там происходят. Понятно, что для этого зависимые вершины должны быть уже просчитаны, поскольку этот метод не терпит циклов в графе.
Соответственно, для того чтобы после этого найти ложноположительные ошибки, мы должны выбрать те учреждения, о которых менеджер читает, что они истинные, при этом их вероятность ниже порогового значения.
В результате в текущей уже реализации, если команда играет в ALPHa Poker в нашем плагине, то фактически по нажатию на кнопки, и после этого некоторого времени вычислений мы можем узнать, в каких местах с большой вероятностью менеджер опережает реальные события.
(00:30:05)
Здесь приведен пример, что фактически менеджер читает, что уже определяется архитектура программной системы, однако при этом не предоставлено ничего из требований, то бишь фактически проектируем систему, то, как выяснили, зачем он вообще нужна и что мы в ней хотим.
Это текущий достигнутый результат. Да, он, конечно, не выглядит значительным, но с точки зрения всех составных частей это было очень тяжелое путешествие к нему. Наверное, с точки зрения общего формата работы это фактически финальный слайд. Дальше – а что тебе с этим можно сделать? Это вроде как импортируем практики и получаем только то, что мы играем, должны играть в ALPHa Poker и прочее. Есть некоторые идеи, разные пути развития. Одна из них –посмотреть теперь не на Essence, посмотреть на другие вещи, которые пытались, так или иначе, вводить стандарты или общее управление проектами, и не только в программной инженерии, типа PM Book, Сbook, (00:31:02) а также из того, что было сделано итого в библиотеке, распространяемой в EPF Composer ___ (00:31:08) 2.0. возможно, там существуют другие способы формально описывать проекты и, возможно, на пересечении с Essence можно выйти на некоторую общую интересную закономерность, которая позволит более детально это все дело прописывать.
Дальше одна из гипотез, которая у меня провалилась, пока я пытался найти ровно этот метод, была основана на подсчете энтропии для определения ошибок менеджеров, но как я потом пересчитал, в моих текущих предположениях теперь то, что сейчас сеть построена экспертом со всеми зависимостями, при наличии появления данных можно переделать алгоритм, чтобы как раз на основании энтропийной зависимости между наблюдаемыми значениями он сеть перестраивал и дооптимизировал, и фактически перейти к вопросу, как от экспертно построенной сеть получить сеть, которая построена не экспертно, а на основании данных какой-то конкретной компании и даже нескольких компаний.
Другой вариант развития – это перейти от общего уровня теоретического контура на уровне ALPHa Poker к конкретным практикам. В чем некоторая особенность подхода сейчас? Сейчас фактически все наблюдаемые свидетельства, которые с точки зрения байесовской теории вероятности очень критичная вещь, это мнения менеджеров. Мы не анализируем, например, написаны, не написаны артефакты для этого самом мнения менеджеров. Однако если спустить логику анализа того, что происходит в проекте, еще на основании того, какие в системе существуют артефакты, на каких они уровнях, что в них написано, а после этого придумать общий язык описания, как это связано с чекбоксами в ALPHa-карточках, потому что этой штуковины в Essence не существует, то дальше можно сделать подходы, при которых фактически менеджер может даже не играть в ALPHa Poker. Он просто запускает алгоритм, алгоритм проверяет, есть в репозитории команды, дальше анализировать семантически, что там написано, и после этого говорить менеджеру, где у него потенциальные проблемы, уязвимости, несостыковки и так далее. Или, например, учитывать мнение менеджера не только как уже и практически единственный источник данных о состоянии проекта, а учитывать его наравне с объективными показателями, формой существования тех или иных артефактов для проекта.
Другой вариант расширения – это посмотреть другие прикладные подходы, математические принципы, которые вполне себе оригинальны, развиваются и решают нестандартные ситуации. Это теория хаоса, мультиагентные системы, самообучающиеся нейронные сети. Я думаю, список можно продолжать очень долго. Но для этого его нужно конкретно знать.
Но практически для всех этих путей развития, с ними придется бороться с двумя очень такими печальными проблемами. Первая проблема в том, что, к сожалению, компания Ivar Jacobson International, который фактически является условным монополистом в области Essence кроме как стандарта, контролирует единственный проприетарный продукт, который позволяет использовать Essence с точки зрения писания формата стандарта, она не сильно хочет делиться накопленными данными по описанию практик и методов, которые они уже сделали.
Второе – то, что если мы говорим по поводу того, что все-таки передать теперь и перейти от академической теории к практической применимости, то нужно найти первую команду или компанию, которая будет готова все-таки немножко рискнуть временем и ресурсами на первичную попытку, потому что, еще раз, пока это фактически концепция, ее нужно апробировать уже в реально боевых условиях. Но поскольку это концепция, то первое апробирование потенциально рискованное.
Все, слайды закончились. Спасибо за внимание. Пожалуйста, вопросы.
Николай Михайловский: Денис, спасибо за очень интересный и бодрый доклад. Так, коллеги, пожалуйста, можно задавать вопросы в Q&A, можно задавать вопросы в чат. Пожалуйста.
(00:35:05)
Пока коллеги собираются с вопросами, я думаю, что для того чтобы оценить возможность внедрения предложенный системы, например, у нас, можно было бы для менеджеров проектов провести некий вебинар про Essence и Essence ALPHa Poker, и это, возможно, помогло бы оценить такую возможность внедрения. Поэтому я предлагаю такую штуку запланировать.
Денис Змеев: Я с удовольствием, но можно после того, как я защищу кандидатскую? Потому что очень долгая слишком история, которую нужно нормально закончить.
Николай Михайловский: Да пожалуйста, защищайте кандидатскую. Это когда будет примерно?
Денис Змеев: Я надеюсь разобраться с этим за лето.
Николай Михайловский: О’кей. Хорошо. Можно, мы немножечко в первые слайды отъедем? А, у нас есть в Q&A, у нас Станислав Капулкин спрашивает: «Денис, знакомы ли вы с теорией категорий?»
Денис Змеев: Скорее всего, нет, в такой формулировке. По крайней мере, я про такую именно теорию отдельно не слышал.
Николай Михайловский: Та теория категорий, про которую я слышал и очень шапочно знаком – это довольно общего рода алгебраическая теория. Но, может быть, мы попросим Станислава пояснить, в связи с чем этот вопрос? Станислав, давайте я вам дам возможность говорить. Я, более того, вас могу в панелисты продвинуть.
Станислав Капулкин: Добрый день. Соответственно, теория категорий – это графический язык визуальный, и часть схем, которые вы приводили на слайдах, они вполне могут быть нарисованы и специалистом по теории категорий. При этом он универсальный математический язык, универсальность его означает, что на нем как раз можно описывать… В принципе, на его основе можно построить и кодогенерацию. Его придумали математики, на нем можно описывать доказательства теорем, то есть можно писать логику вычислений каких-нибудь в теореме с доказательством, почему эти вычисления соответственно ведут к какому-то правильному ответу. А можно там описывать вычисления соответственно и кодогенерить по ним код. По-моему, это выглядит хорошо для расширения Essence, вы говорили в конце, что в Essence нету части по описанию задач, которые… Последнее, что вы говорили, что если в Essence добавить в каком-то виде описание задач, то можно убрать даже ALPHa Poker, заменив все это на какую-то автоматическую верификацию. Теория категорий потенциально для этого подходит.
Денис Змеев: Хорошо. В таком случае я посмотрю, я говорил немножко другое. В Essence и в ALPHa Poker фиксируются вот такие вот чекбоксики, это утверждения. Сейчас в теории Essence нет фразы о том, как, например, если я использую product backlog или что-нибудь еще, как непосредственно вещи, которые я делаю на уровне артефактов типа сценариев, вариантов использования, какие именно чекбоксики они должны потенциально поставить. Это отдано на откуп экспертного мнения менеджера, аналитика, архитектора и так далее.
Если мы говорим про штуковину, которая анализирует проект за человека, соответственно, нужно сделать какой-то язык, который хотя бы постарается эти вещи связать. Использовать для этого теорию категорий – да, возможно, но тут надо будет долго копаться, потому что в любом случае вопрос, а сможем ли мы сделать инструмент, который будет поддерживать одновременно и Essence, и теорию категорий.
Николай Михайловский: Возможно, мы можем попросить Станислава прислать какие-то ссылки на какие-то тексты, связанные с теорией категорий, для того чтобы иметь единое представление о том, о чем идет речь.
Станислав Капулкин: Я думаю, что я буду рад чуть позже сделать отдельный доклад на эту тему. У меня уже есть публичное выступление, но в какой-то момент появятся, накопятся еще материалы новые, с которыми можно будет, например, провести хорошую лекцию.
(00:39:56)
Николай Михайловский: Как будете, готовы пишите мне, и обсудим ваше выступление потенциальное.
Денис, если вернуться назад, назад, назад, в самое начало, в управление проектами в программной инженерии, чем бы хотелось вот это дополнить? Посыл следующий. Во-первых, проекты из области программной инженерии относятся к классу разработки технологий по определению. Класс разработки технологий – это такой класс видов деятельности, в которых мы, познавая некий процесс, выстраиваем некую технологическую обвязку для процессов. Некоей ключевой деятельностью в программной инженерии является познание некоего процесса. Это познание процесса может происходить как в виде выявления требований, то есть, по сути, в разговорах, так и в виде, например, отгрузки в клиентскую среду неких решений и наблюдения того, что после этого происходит, да, то есть чего нам заказчик в ответ на это сказал, и вообще, стали ли этим пользоваться.
Таким образом, поскольку мы говорим о познании в принципе, то в программно-инженерном проекте происходит высказывание некоторых гипотез и тестирование границ их применения, поскольку это общая схема любого процесса познания. Таким образом, у нас еще одним взглядом на то, что происходит в проекте программной инженерии, состоит в том, что у нас есть некоторое количество гипотез, которые, в том числе можно описывать и с байесовской точки зрения, а дальше мы эти гипотезы проверяем или определяем их границы применимости, что тоже неким образом в байесовский фреймворк, как мне кажется, укладывается.
Есть еще один аспект того, что я говорю. Этот аспект связан со сжатием информации, скажем так. Поскольку когда мы высказываем некую гипотезу, когда вы строим любую модель, а в ходе программной инженерии мы строим модели, мы занимаемся тем, что отбрасываем информацию, которая неважна для нашей модели. Таким образом, построение моделей, в том числе в рамках программной инженерии, есть процесс сжатия информации об объекте автоматизации. Мы нечто об объекте автоматизации отбрасываем, а нечто оставляем в проекте, с очевидностью.
Таким образом, на то тестирование гипотез и на байесовскую историю, которую мы только что обсудили, можно смотреть еще и с этой точки зрения: какая информация отбрасывается и какая информация остается внутри проекта. Обычно то, что я говорю сейчас, интерпретируется в виде рисков проекта, но возможна интерпретация и с точки зрения информации. Я призываю неким образом подумать и в эту сторону тоже, потому что, кажется, что там может быть прикопано что-то интересное.
Денис Змеев: Сюда же можно попробовать и прикопать принятие решений по байасу в условиях ограниченности информации для ограниченности ресурсов на проверку гипотез.
Николай Михайловский: И так на это можно смотреть тоже, да. Там есть достаточно широкое поле, связанное как с базовыми байесовскими подходами, так и, например, с ограниченностью ресурсов, тоже, пожалуйста.
(00:45:01)
Антон Воронов спрашивает: «Через какое время возможно внедрение на реальном проекте реальной компании?»
Денис Змеев: Технически плагин для Redmine уже готов, и на самом деле для первой попытки внедрения он даже не нужен, надо просто играть в ALPHa Poker. Дальше просто вопрос – либо мы тратим время менеджеров, чтобы они разобрались в ALPHa Poker, либо вы допускаете исследователей к вашему состоянию проекта, даже с NDA, не с NDA, просто для проверки применимости. После этого… Как минимум первые результаты можно будет получить очень быстро, фактически ввести данные, прогнать алгоритм, через пятнадцать минут все заработало. Если текущий результат, получается, что вопрос буквально вот: понять, в какой проект ввести данные, поехали. А если мы говорим про полноценное, именно полная процедура, полная автоматизация и так далее, тут до бесконечности можно делать, если честно.
Николай Михайловский: Возможно ли внедрение того, что обсуждалось, без процедуры ALPHa Poker вообще?
Денис Змеев: Сейчас ALPHa Poker для нас – это модель общего описания проекта, другой у меня пока нету. Можно сделать как? Можно просто пригласить, условно, меня, я пообщаюсь с менеджером и так далее, буду с ними регулярно общаться, сам все переносить в ALPHa Poker, а после этого соответственно мы будем получать какие-то утверждения, потенциально рискованные.
Николай Михайловский: Так, кажется, больше у нас вопросов нету. Денис, еще раз спасибо за интересное выступление. Я думаю, после защиты диссертации мы еще пообщаемся более подробно.
Денис Змеев: Хорошо.
Николай Михайловский: Спасибо. До свидания, до новых встреч.
(00:00:00) (Конец записи)