Учёт потраченного времени целесообразен только в аутстафф/аутсорс конторах. Потому, что они продают часы и по ним нужно выставлять счета. Если же проект продается по фиксе, то важно не "сколько часов туда вбухали", а "за сколько времени проект сделали" и сколько календарного времени (в рабочих днях) потрачено на задачу. Потому что операционные затраты постоянно идут, и чем раньше будет сделан проект, тем больше выгода на экономии операционных затрат.
Но даже при просрочке проектов, эти компании научились "отбивать" все увеличения сроков доп. соглашениями.
Мы, как разработчики второго (Пульса), то его и применяем %)) Я лично пробовал давно другие решения, но там как без рук. Для простых ответов на вопросы (когда освободится сотрудник, задачи по сотрудникам) нужно городить какие-то хитрые отчёты вместо одного клика.
Некоторые Клиенты ставят Пульс в интеграцию в Jira/Trello чтобы видеть всю картину, а не разбитую по пространствам/доскам. Другие ставят вместо BigPicture/Structure, чтобы нормальное календарно-сетевое планирование поверх трекера было.
Если просто менять этот стек, то Eva позиционирует себя как замена. Если же со сменой хочется еще ускорить проекты и добавить ресурсное планирование, то в BIPULSE есть интеграция с Trello и Jira , но тут в нагрузку приедет и обновление методологии управления. (Управление проектами критической цепи (Critical chain Project management) и адаптация этого для Agile проектов)
C BINDом понятно. я говорю про dkim_signing в RPAMD, который должен вставлять подпись DKIM в заголовок письма. Что-то у меня не вставляет. Уже и так и этак, в базе mailu вообще /dkim приватный ключ не предоставляет в контейнер antispam (rspamd).
Риски в сроки нужно закладывать правильно, иначе сработает Закон Паркинсона. Способ резервирования и контроля я в Методе рассказываю.
А на всякие вопросы "когда закончим" система умеет отвечать. Даже если её поставить "поверх другой системы". Хотя если проектов до 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 файлов.
Учёт потраченного времени целесообразен только в аутстафф/аутсорс конторах. Потому, что они продают часы и по ним нужно выставлять счета. Если же проект продается по фиксе, то важно не "сколько часов туда вбухали", а "за сколько времени проект сделали" и сколько календарного времени (в рабочих днях) потрачено на задачу. Потому что операционные затраты постоянно идут, и чем раньше будет сделан проект, тем больше выгода на экономии операционных затрат.
Но даже при просрочке проектов, эти компании научились "отбивать" все увеличения сроков доп. соглашениями.
Мы, как разработчики второго (Пульса), то его и применяем %))
Я лично пробовал давно другие решения, но там как без рук. Для простых ответов на вопросы (когда освободится сотрудник, задачи по сотрудникам) нужно городить какие-то хитрые отчёты вместо одного клика.
Некоторые Клиенты ставят Пульс в интеграцию в Jira/Trello чтобы видеть всю картину, а не разбитую по пространствам/доскам. Другие ставят вместо BigPicture/Structure, чтобы нормальное календарно-сетевое планирование поверх трекера было.
Если просто менять этот стек, то Eva позиционирует себя как замена. Если же со сменой хочется еще ускорить проекты и добавить ресурсное планирование, то в BIPULSE есть интеграция с Trello и Jira , но тут в нагрузку приедет и обновление методологии управления. (Управление проектами критической цепи (Critical chain Project management) и адаптация этого для Agile проектов)
C BINDом понятно. я говорю про dkim_signing в RPAMD, который должен вставлять подпись DKIM в заголовок письма. Что-то у меня не вставляет. Уже и так и этак, в базе mailu вообще /dkim приватный ключ не предоставляет в контейнер antispam (rspamd).
А удалось ли поднять DKIM подпись исходящих писем в mailu?
Риски в сроки нужно закладывать правильно, иначе сработает Закон Паркинсона. Способ резервирования и контроля я в Методе рассказываю.
А на всякие вопросы "когда закончим" система умеет отвечать. Даже если её поставить "поверх другой системы". Хотя если проектов до 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 файлов.