Риски в сроки нужно закладывать правильно, иначе сработает Закон Паркинсона. Способ резервирования и контроля я в Методе рассказываю.
А на всякие вопросы "когда закончим" система умеет отвечать. Даже если её поставить "поверх другой системы". Хотя если проектов до 5 и это ИТ, то всё в эксельке можно посчитать, если данные об объемах есть на основе внесения трёх показателей: текущая дата, всего работы, сделано работы. (остальные копируются с прошлых ячеек)
(прошло 2 года) Теперь есть Телеграм-бот. Для монтажников и бригадиров есть команда "Указать сколько дней надо для завершения задачи". Для ГИП-ов , когда побывал на площадке потом заполнил статус - есть в веб-версии "заполнение отчёта" чтобы массово заполнить состояние по задачам.
Для упрощения эргономики - мы добавили "однопроектный режим" - чтобы было "как в других трекерах" и настройку словаря под сферу применения.
По прошествии времени оказывается что, основной клиент которому нужны "проекты в срок или раньше" это строители (не все), проектировщики, конструктора. В ИТ-сфере, к сожалению, принято продалбывать сроки или "закрывать проекты печенью".
Про Метод стыковки Agile с проектами есть в книге "Управление проектным бизнесом" https://pulsemanagement.org/ Хотя у PMI мощности побольше, но большая часть участников сообщества это из стройки, а никак не из разработки ПО.
PMI внезапно "обнаружили", что у них есть большая ниша, для которой они ничего не сделали. Это ИТ-проекты с их особенностями и решили как-то адаптировать (это же сколько членских взносов можно собрать с ИТ-менеджеров!!).
Но я рад, что, как минимум, они показывают варианты стыковки. Если говорить про способы управления для ИТ-проектов то тут будет работать схема:
Фаза 1 (Внедрение) - если ищем решение, то делаем проект итерационно по Скраму, если цель понятна - то как обычно с постановкой цели и планированием. Фаза 2 (Развитие) - обычно цели развития понятны, делаем как обычно с постановкой цели и планированием. Фаза 3 (Эксплуатация) - это сопровождение готового изделия, поэтому Канбан-метод, ITSM, ITIL и всё такое будет эффективным. главное разделять где заявка а где проект.
Фаза 4 (Вывод из использования) - продолжаем обслуживание по Канбан-методу, ITSM, ITIL пока не закончится гарантийный срок, и запускаем проект с целями, планированием.
На уровне исполнения на всех фазах может быть что-то итерационное, как коммуникационный каркас.
Ключевое, как я писал про наш опыт миграции, быстрая проверка - быстрое исполнение.
PHP даёт быструю проверку. После сборки - быстрое исполнение. Также часть абстракций C++ уходит в DSL на PHP и с ними проще работать. Мы думали о переходе в одну сторону.. Это становится дороже в разработке.
Обращения к полям по имени - можно! Мы же сделали. Для этого пришлось сделать свою рефлексию с автогеном. Но сам PHP по этому же пути пошёл добавив классы рефлексии.
У нашей команды есть девиз: Когда нельзя, но очень хочется, то можно. Потому что бизнес диктует одно, а технологии определяют другое. приходится вертеться.
Но такой большой рефакторинг у нас не первый, предыдущей была миграция с XSLT на JS/React - там пришлось реализовать свою версию XSL для JS-объектов чтобы сохранить гибкость интерфейса.
по поднятым вопросам: 1. система вошла, получается, в зависимость от проекта ВК,
а) ВК на нем очень устойчиво развивается и работает. б) Мы конечно сделали клон себе на гитхаб и затянули локально, так как залезли внутрь. Поэтому даже если ВК по каким-то причинам остановит работу, код уже ушел. Текущего синтаксиса PHP 7.4 хватает для наших задач.
2. большая часть времени выполнения висит в ожидании I/O от БД.
Это верно, но в движке KPHP есть возможности кеширования в памяти (даже между воркерами), поэтому часть операций мы не выполняем если можно что-то не выполнять.
Если говорить о числодробилке, то её мы ускорили, но не достаточно как хотелось бы, и будем делать следующую версию чтобы вычисления при корректировке расписания проектов не ходили в БДс совсем.
3 Выглядит так, что основной плюс - хорошая обфускация, но стоит ли она полгода разработки - неясно.
а) Ну если назвать обфускацией перевод в машинные коды, то да. Но тут выгода в том, что можно накрыть защитой типа Guardant (правда при первом пуске он сломался) и сделать нормальную лицензию.
б) Развертывание теперь делается проще и без ошибок
в) Проверка типов выполняется при сборке, а значит тоже меньше ошибок.
Итог по всем пунктам: за это стоило биться полгода.
Вопрос в том, ЧТО именно проверяют модульные тесты. Часто тесты проверяют логику работы приложения, и для это логики без разницы какая БД используется, так как ORM убирает базовые операции под капот.
Если же используются специфичные вещи, как например регистронезавимый LIKE или json_* операции, то такие лучше проверять в целевой СУБД. Но обычно, такие тесты размещаются в подсистеме работы с БД у которой свои тесты которые могут подключаться к целевой БД.
С другой стороны, в модульных тестах можно использовать одну конфигурацию тестовой БД, а вот приемочные тесты гонять на всех конфигурациях СУБД. То что мы ошибку не увидим быстро это минус, но переусложнять тестовую среду тоже не вариант.
У нас в системе используются комбинированные тесты: там где есть зависимость от движка - есть модульные тесты движка, где нету - используется Sqlite в памяти.
Сейчас на рынке только двое (по словам Клиентов) умеют планировать ресурсы: BIPULSE и Spider Project. И оба с методической составляющей. Потому, что как только появляется выравнивание ресурсов для многопроектной среды требуется объяснение "а как с этим работать?". Но не все поставщики ИСУП готовы ввязываться в историю с внедрением методики (только евангелисты).
При внедрении Пульса (BIPULSE) такое (с AD) можно прикрутить. Но это сильно частный случай и нужен только в очень больших компаниях.
Сейчас назначать можно и так всех кто доступен. Если начальник отдела доступен- значит ему ставится задача, дальше он может её разбить. Мы называем это "двух-уровневое управление проектом"
Если про интеграцию: то Пульс может зеркалировать или гонять в обе стороны всю структуру работ внешней системы, к выпуску планируется "частичная интеграция" для обогащения элементов системы внешними данными.
Переписать всегда можно, и даже инвестировать туда кучу ресурсов но... переход на С++ убьёт одну небольшую возможность: БЫСТРАЯ ПРОВЕРКА.
Мы после миграции на KPHP этим активно пользуемся, получается очень мощна связка: Быстрая проверка (в PHP режиме) и Быстрое исполнение (в KPHP сборке).
В С++ проекте чтобы проверить "А как оно выглядит" нужно ждать сборки, это даёт хороший эффект - архитектура становится лучше (потому что работает Закон Васильева). Но... замедляется проверка идей.
Закон Васильева о квалификации разработчика ПО: Время необходимое инженеру для достижения уровня "Профессионал" обратно пропорционально времени сборки сборки проекта. Обоснование Закона: Чем дольше собирается проект, тем больше разработчик не хочет ждать этой сборки, тем тщательней он проектирует систему на бумаге. Тем быстрее растёт его квалификация в разработке ПО. Доказательство Закона: сравните знания по ООП у С++ и веб-разработчика с трёх-летним стажем.
О! Это элементарно! У нас как раз то, о чем говорите "планировщик, оптимизатор", и тд, но для расписания проектов. Общая сборка: 21.000 целей для сборки после KPHP. На выходе c -ggdb почти 2 гига бинарник, без этого 211M. Из них сам рантайм (реализация всех PHP-функций) где-то 70М весит.
Хотя на входе исходных файлов меньше, около 5000. При этом У нас автогенеренного кода еще много-много создаётся (ибо нету в KPHP рефлексии , пришлось написать).
Поэтому, основной объём идёт чисто от автогенерации кода, которая нужна для ускорения. А сам планировщик - там кода очень немного, всего 90 файлов.
Эта зверюга, KPHP, генерит файлы по каждой функции. И хотя имя каждого файла уникальное, но оно зависит от сигнатуры методов. Иногда поменяешь в одном месте а в сборку уходит 8000 целей. Потому что класс наследуется....
Мы тут миграцию на KPHP сделали, теперь приходится работать в режиме "это почти С++" %)) Хотя быстрая проверка алгоритмов в режиме PHP тоже доступна. Во вторник статью выпущу про нашу миграцию.
По сравнению с тем что в системе (Ubuntu 21) [gost89, gost89-cnt, gost89-cnt-12, gost89-cbc, grasshopper-ecb, grasshopper-cbc, grasshopper-cfb, grasshopper-ofb, grasshopper-ctr, md_gost94, gost-mac, md_gost12_256, md_gost12_512, gost-mac-12, gost2001, gost-mac, gost2012_256, gost2012_512, gost-mac-12]
НО! Они все не помогают для ключа полученного в декабре 21 года в Тензоре. Крипто-Про не видит закрытого ключа, openssl в сборке находит целых ноль байт. Схема VipNet Windows10 -> PFX -> openssl ....
Вопрос: а в каком ГОСТе сейчас ключи выдают? Или это в виндах что-то нахимичили с шифрованием?
Оба-на, подскаст со мной! Рад что еще кто-то заинтересовался ТОС.
О шагах: Если быть более точным, то второй шаг "РЕШИТЬ, как максимизировать работу ограничения" - "Decide how to EXPLOIT the system's constraint(s)." - в словаре TOCICO.
О внедрении: Пять направляющих шагов простые, НО это это только кажется. Чтобы внедрить найденное решение необходимо пройти по всем слоям сопротивления. То есть как минимум:
1. Отсечь негативные ветви (см Дерево будущей реальности) 2. Выявить препятствия и найти промежуточные цели для преодоления препятствий (см. Дерево перехода aka "prerequisite tree")
О границах применимости:
Из роли разработчика тоже можно менять систему. И для этого у вас есть Ретроспектива спринта. И я уверен, что есть даже кросс-командная Ретроспектива. Ретроспектива - Это основная точка изменений в компании. Это основная точка убеждения в том, что проблема существует. Если "клиент" не принял что "проблема существует", то любые изменения утонут.
Сейчас вышла книга "Управление проектным бизнесом" https://ridero.ru/books/upravlenie_proektnym_biznesom/ о том как скрестить Agile с Методом Критической Цепи так, чтобы это работало. В принципе Метод будет также хорошо работать и для LeSS команд и для управления конфигурацией, потому как планирование с применением "дерева предпосылок" обеспечивает выстраивание всей работы команд и зависимостей.
О метриках ТОС:
Для ИТ-компании связанный капитал и операционные затраты величины постоянные. На Проход внутри ИТ-отдела влияние небольшое, поэтому единственное что остается: "Скорость генерации единиц цели".
В 5 направляющих шагах есть еще 2: -1 Шаг: Определить границы системы 0 Шаг: Определить цель системы.
Если Цель системы - выкатывать больше изменений в единицу времени - то это хорошая тема для обсуждения. (Но так ли это?)
Риски в сроки нужно закладывать правильно, иначе сработает Закон Паркинсона. Способ резервирования и контроля я в Методе рассказываю.
А на всякие вопросы "когда закончим" система умеет отвечать. Даже если её поставить "поверх другой системы". Хотя если проектов до 5 и это ИТ, то всё в эксельке можно посчитать, если данные об объемах есть на основе внесения трёх показателей: текущая дата, всего работы, сделано работы. (остальные копируются с прошлых ячеек)
(прошло 2 года) Теперь есть Телеграм-бот. Для монтажников и бригадиров есть команда "Указать сколько дней надо для завершения задачи".
Для ГИП-ов , когда побывал на площадке потом заполнил статус - есть в веб-версии "заполнение отчёта" чтобы массово заполнить состояние по задачам.
Для упрощения эргономики - мы добавили "однопроектный режим" - чтобы было "как в других трекерах" и настройку словаря под сферу применения.
По прошествии времени оказывается что, основной клиент которому нужны "проекты в срок или раньше" это строители (не все), проектировщики, конструктора. В ИТ-сфере, к сожалению, принято продалбывать сроки или "закрывать проекты печенью".
Про Метод стыковки Agile с проектами есть в книге "Управление проектным бизнесом" https://pulsemanagement.org/
Хотя у PMI мощности побольше, но большая часть участников сообщества это из стройки, а никак не из разработки ПО.
PMI внезапно "обнаружили", что у них есть большая ниша, для которой они ничего не сделали. Это ИТ-проекты с их особенностями и решили как-то адаптировать (это же сколько членских взносов можно собрать с ИТ-менеджеров!!).
Но я рад, что, как минимум, они показывают варианты стыковки.
Если говорить про способы управления для ИТ-проектов то тут будет работать схема:
Фаза 1 (Внедрение) - если ищем решение, то делаем проект итерационно по Скраму, если цель понятна - то как обычно с постановкой цели и планированием.
Фаза 2 (Развитие) - обычно цели развития понятны, делаем как обычно с постановкой цели и планированием.
Фаза 3 (Эксплуатация) - это сопровождение готового изделия, поэтому Канбан-метод, ITSM, ITIL и всё такое будет эффективным. главное разделять где заявка а где проект.
Фаза 4 (Вывод из использования) - продолжаем обслуживание по Канбан-методу, ITSM, ITIL пока не закончится гарантийный срок, и запускаем проект с целями, планированием.
На уровне исполнения на всех фазах может быть что-то итерационное, как коммуникационный каркас.
Ключевое, как я писал про наш опыт миграции, быстрая проверка - быстрое исполнение.
PHP даёт быструю проверку. После сборки - быстрое исполнение. Также часть абстракций C++ уходит в DSL на PHP и с ними проще работать. Мы думали о переходе в одну сторону.. Это становится дороже в разработке.
Обращения к полям по имени - можно! Мы же сделали. Для этого пришлось сделать свою рефлексию с автогеном. Но сам PHP по этому же пути пошёл добавив классы рефлексии.
У нашей команды есть девиз: Когда нельзя, но очень хочется, то можно. Потому что бизнес диктует одно, а технологии определяют другое. приходится вертеться.
Но такой большой рефакторинг у нас не первый, предыдущей была миграция с XSLT на JS/React - там пришлось реализовать свою версию XSL для JS-объектов чтобы сохранить гибкость интерфейса.
Тут не только ускорение было целью. Но еще и бизнесовая составляющая: закрыть исходники.
На VC вторая часть статьи про бизнесовый контекст.
https://vc.ru/services/526585-kak-my-oblachnyy-php-servis-zavernuli-v-korobku-s-zashchitoy-licenziey-i-pri-etom-uskorilis
по поднятым вопросам:
1. система вошла, получается, в зависимость от проекта ВК,
а) ВК на нем очень устойчиво развивается и работает.
б) Мы конечно сделали клон себе на гитхаб и затянули локально, так как залезли внутрь.
Поэтому даже если ВК по каким-то причинам остановит работу, код уже ушел. Текущего синтаксиса PHP 7.4 хватает для наших задач.
2. большая часть времени выполнения висит в ожидании I/O от БД.
Это верно, но в движке KPHP есть возможности кеширования в памяти (даже между воркерами), поэтому часть операций мы не выполняем если можно что-то не выполнять.
Если говорить о числодробилке, то её мы ускорили, но не достаточно как хотелось бы, и будем делать следующую версию чтобы вычисления при корректировке расписания проектов не ходили в БДс совсем.
3 Выглядит так, что основной плюс - хорошая обфускация, но стоит ли она полгода разработки - неясно.
а) Ну если назвать обфускацией перевод в машинные коды, то да. Но тут выгода в том, что можно накрыть защитой типа Guardant (правда при первом пуске он сломался) и сделать нормальную лицензию.
б) Развертывание теперь делается проще и без ошибок
в) Проверка типов выполняется при сборке, а значит тоже меньше ошибок.
Итог по всем пунктам: за это стоило биться полгода.
Вопрос в том, ЧТО именно проверяют модульные тесты. Часто тесты проверяют логику работы приложения, и для это логики без разницы какая БД используется, так как ORM убирает базовые операции под капот.
Если же используются специфичные вещи, как например регистронезавимый LIKE или json_* операции, то такие лучше проверять в целевой СУБД. Но обычно, такие тесты размещаются в подсистеме работы с БД у которой свои тесты которые могут подключаться к целевой БД.
С другой стороны, в модульных тестах можно использовать одну конфигурацию тестовой БД, а вот приемочные тесты гонять на всех конфигурациях СУБД. То что мы ошибку не увидим быстро это минус, но переусложнять тестовую среду тоже не вариант.
У нас в системе используются комбинированные тесты: там где есть зависимость от движка - есть модульные тесты движка, где нету - используется Sqlite в памяти.
Система BIPULSE https://bipulse.ru/
Без FFI фокус бы не получился, мы прорабатывали схему с прокси для БД. Но FFI вовремя подоспел
PHP 7.4, но в коде были хвоcты еще от PHP4. Сейчас тесты гоняются в обоих режимах PHP/KPHP под обе СУБД (Sqlite, PostgresSQL).
Сейчас на рынке только двое (по словам Клиентов) умеют планировать ресурсы: BIPULSE и Spider Project. И оба с методической составляющей. Потому, что как только появляется выравнивание ресурсов для многопроектной среды требуется объяснение "а как с этим работать?". Но не все поставщики ИСУП готовы ввязываться в историю с внедрением методики (только евангелисты).
При внедрении Пульса (BIPULSE) такое (с AD) можно прикрутить. Но это сильно частный случай и нужен только в очень больших компаниях.
Сейчас назначать можно и так всех кто доступен. Если начальник отдела доступен- значит ему ставится задача, дальше он может её разбить. Мы называем это "двух-уровневое управление проектом"
Если про интеграцию: то Пульс может зеркалировать или гонять в обе стороны всю структуру работ внешней системы, к выпуску планируется "частичная интеграция" для обогащения элементов системы внешними данными.
Переписать всегда можно, и даже инвестировать туда кучу ресурсов но... переход на С++ убьёт одну небольшую возможность: БЫСТРАЯ ПРОВЕРКА.
Мы после миграции на KPHP этим активно пользуемся, получается очень мощна связка: Быстрая проверка (
вPHP режиме) и Быстрое исполнение (в KPHP сборке).В С++ проекте чтобы проверить "А как оно выглядит" нужно ждать сборки, это даёт хороший эффект - архитектура становится лучше (потому что работает Закон Васильева). Но... замедляется проверка идей.
Закон Васильева о квалификации разработчика ПО: Время необходимое инженеру для достижения уровня "Профессионал" обратно пропорционально времени сборки сборки проекта.
Обоснование Закона: Чем дольше собирается проект, тем больше разработчик не хочет ждать этой сборки, тем тщательней он проектирует систему на бумаге. Тем быстрее растёт его квалификация в разработке ПО.
Доказательство Закона: сравните знания по ООП у С++ и веб-разработчика с трёх-летним стажем.
О! Это элементарно! У нас как раз то, о чем говорите "планировщик, оптимизатор", и тд, но для расписания проектов. Общая сборка: 21.000 целей для сборки после KPHP. На выходе c -ggdb почти 2 гига бинарник, без этого 211M. Из них сам рантайм (реализация всех PHP-функций) где-то 70М весит.
Хотя на входе исходных файлов меньше, около 5000. При этом У нас автогенеренного кода еще много-много создаётся (ибо нету в KPHP рефлексии , пришлось написать).
Поэтому, основной объём идёт чисто от автогенерации кода, которая нужна для ускорения. А сам планировщик - там кода очень немного, всего 90 файлов.
Эта зверюга, KPHP, генерит файлы по каждой функции. И хотя имя каждого файла уникальное, но оно зависит от сигнатуры методов. Иногда поменяешь в одном месте а в сборку уходит 8000 целей. Потому что класс наследуется....
Мы тут миграцию на KPHP сделали, теперь приходится работать в режиме "это почти С++" %)) Хотя быстрая проверка алгоритмов в режиме PHP тоже доступна. Во вторник статью выпущу про нашу миграцию.
Отличные новости! Теперь бы еще для PostgreSQL сделать обвязку ;)
В докер-образе видимо побольше этих ГОСТов. [gost89, gost89-cnt, gost89-cnt-12, gost89-cbc, grasshopper-ecb, grasshopper-cbc, grasshopper-cfb, grasshopper-ofb, grasshopper-ctr, magma-cbc, magma-ctr, id-tc26-cipher-gostr3412-2015-kuznyechik-ctracpkm, md_gost94, gost-mac, md_gost12_256, md_gost12_512, gost-mac-12, magma-mac, grasshopper-mac, id-tc26-cipher-gostr3412-2015-kuznyechik-ctracpkm-omac, gost2001, gost-mac, gost2012_256, gost2012_512, gost-mac-12, magma-mac, grasshopper-mac, id-tc26-cipher-gostr3412-2015-magma-ctracpkm-omac, id-tc26-cipher-gostr3412-2015-kuznyechik-ctracpkm-omac]
По сравнению с тем что в системе (Ubuntu 21)
[gost89, gost89-cnt, gost89-cnt-12, gost89-cbc, grasshopper-ecb, grasshopper-cbc, grasshopper-cfb, grasshopper-ofb, grasshopper-ctr, md_gost94, gost-mac, md_gost12_256, md_gost12_512, gost-mac-12, gost2001, gost-mac, gost2012_256, gost2012_512, gost-mac-12]
НО! Они все не помогают для ключа полученного в декабре 21 года в Тензоре.
Крипто-Про не видит закрытого ключа, openssl в сборке находит целых ноль байт.
Схема VipNet Windows10 -> PFX -> openssl ....
Вопрос: а в каком ГОСТе сейчас ключи выдают? Или это в виндах что-то нахимичили с шифрованием?
Сервера по сравнению с ФОТ небольшие затраты.
Оба-на, подскаст со мной! Рад что еще кто-то заинтересовался ТОС.
О шагах:
Если быть более точным, то второй шаг "РЕШИТЬ, как максимизировать работу ограничения" - "Decide how to EXPLOIT the system's constraint(s)." - в словаре TOCICO.
О внедрении:
Пять направляющих шагов простые, НО это это только кажется. Чтобы внедрить найденное решение необходимо пройти по всем слоям сопротивления. То есть как минимум:
1. Отсечь негативные ветви (см Дерево будущей реальности)
2. Выявить препятствия и найти промежуточные цели для преодоления препятствий (см. Дерево перехода aka "prerequisite tree")
О границах применимости:
Из роли разработчика тоже можно менять систему. И для этого у вас есть Ретроспектива спринта. И я уверен, что есть даже кросс-командная Ретроспектива. Ретроспектива - Это основная точка изменений в компании. Это основная точка убеждения в том, что проблема существует. Если "клиент" не принял что "проблема существует", то любые изменения утонут.
О Методе критической цепи для ИТ-проектов
Я уже начинал цикл статей о Методе (читать отсюда https://habr.com/ru/post/462423/ )
Сейчас вышла книга "Управление проектным бизнесом" https://ridero.ru/books/upravlenie_proektnym_biznesom/ о том как скрестить Agile с Методом Критической Цепи так, чтобы это работало. В принципе Метод будет также хорошо работать и для LeSS команд и для управления конфигурацией, потому как планирование с применением "дерева предпосылок" обеспечивает выстраивание всей работы команд и зависимостей.
О метриках ТОС:
Для ИТ-компании связанный капитал и операционные затраты величины постоянные. На Проход внутри ИТ-отдела влияние небольшое, поэтому единственное что остается: "Скорость генерации единиц цели".
В 5 направляющих шагах есть еще 2:
-1 Шаг: Определить границы системы
0 Шаг: Определить цель системы.
Если Цель системы - выкатывать больше изменений в единицу времени - то это хорошая тема для обсуждения. (Но так ли это?)