P.S. Было бы неплохо услышать доклад/статью про "мы переехали с Go на PHP и вот что получилось". Вангую, там бы тоже получили ускорение и удешевление.
Есть "Мы переехали с PHP на KPHP", https://habr.com/ru/articles/686496/ ускорение точно есть и по опыту нагрузочных тестов - удешевление инфраструктуры. Мы когда из интеграционных тестов небольшие скрипты через PHP-FPM дергали, то память расходовалась сильно. Добавили эти части в состав основного KPHP-сервера приложения - стало все идеально.
Можно и на С++ настолько плохо написать, что будут жраться ресурсы как не в себя. В 2004 году я переписывал счётчик HotLog (если кто-то помнит такой), Была производительность 100 хитов/секунду, стало 5000 хитов в секунду. Причина: применялась "копирка" c Perl с коллекциями (хеши). После рефакоринга на правильные типы данные и правильные коллекции (rbtree) скорость заметно выросла и количество необходимых серверов уменьшилось.
Есть KPHP - статическая типизация с "авто" выводом типов, и сборкой в нативный бинарник. (под капотом C++) Совместимость с PHP обеспечивает быстрые проверки, а после сборки - быстрое исполнение.
Во первых, Скрам НЕ МЕТОДОЛОГИЯ! А процессный каркас, о чем прямо указано в Руководстве.
Во вторых, Скрам без XP для ИТ-проектов - что пиво без водки.
В третьих - Вы можете сколько угодно смотреть в трекер задач, но бизнес-человек хочет ПОСМОТРЕТЬ В ГЛАЗА и спросить "А не лапшу ли ты вешаешь, мил человек?" . Впрочем из истории Скрама именно эта практика и была вполне успешной (см. в книге Сазерленда) . Потому, что только сравнив план и факт можно задать вопрос глядя в глаза и нужные принять решения и относительно проекта и относительно людей в нём.
Вот так хорошо начал. Скрам плохо здесь, Скрам плохо там. Я подумал что, вот оно, сейчас приземлят на потребности бизнеса, и.... внезапно "Возьмите Канбан в нем нет оценок" я прямо осёкся.
Скрам отлично подходит для своей среды. Особенно, если вы не знаете куда идти. И особенно если Клиент не знает куда идти и какую цель достигать. Но в RnD проектах ЕСТЬ ЦЕЛЬ. Просто часто непонятно "КАК её достигнуть". Ну так может сесть и подумать? Для этого даже специально обученные люди были.... как их там?... а вот вспомнил! Архитектор программного обеспечения!
А если вы не знаете куда идти, так может остановиться с просить Клиента, " А ты, вообще, какую проблему решаешь?"
Совещания здесь плохо, совещания там плохо. А ничего, что стандартного бизнес-человека беспокоит два вопроса: 1. Что происходит? 2. Когда будет готово?
И ему главное чтобы было: Сказал - сделал. Или выполняй обещания или не обещай. Правильные спринты Скрама дают эту прозрачность. Да и неправильные спринты тоже дают это. Только это называется "план-фактный анализ" и проводится каждую неделю. Часто никак даже не называется потому, что в понедельник нужно понять "Чем они будут заняты и почему я должен им платить?"
Продукты: A-Dato LYNX, Exepron, Pro Chain, BeingManagement3, BIPULSE. Из российских только BIPULSE. Обычные продукты CCPM не умеют, это специализированный софт только может.
Прошёл еще +1 год, в 2023 году появилась функция "Заполнить отчёт", чтобы быстро пробежаться по всем и указать какой физический объем выполнен и сколько дней еще нужно. Как раз для обзвона всех и отмечания прогресса.
Также мы завершили все работы с упаковкой в коробочную версию (вот буквально бинарник, на KPHP) и есть поставка на AstraLinux. И выпустили версию для рабочего стола "BIPULSE. АРМ Планировщик", как замену MS Project Pro.
За время пути собака смогла подрасти, вышел новый сервис АвтоГантт. По функциям - умеет выравнивать ресурсы и показывать плановую загрузку. Ресурсное планирование не в формате "сейчас укажем занятость 8-8-8-8-8 часов, а потом будем искать превышение", а "Вот на этих задачах у меня занят сотрудник, сделай мне магию, сдвинь задачи"
Точнее сказать оценка в часах годится только для "нормированной работы". Нормированная работа - работа для которой есть нормо-часы, как автосервисе, на стройке, на производстве.
В последнее время я замечаю что вся непредсказуемость возникает из-за.... "Да ну нафиг оценивать в днях, давай в майках, или вообще не будем оценивать.". А потом начинаются попытки применить "процессы поддержки" где SLA есть и атомарность для основной разработки. И в итоге "статистика что-то не очень".
>Было бы любопытно посмотреть на ситуацию, когда контора получает лицензию на производство определённого ПО только при наличии заранее созданного набора инструментов.
Это называется "Сертификация компании по уровню CMMI", правда Мотороле это не очень помогло, но модель хорошая и понятная.
>А ещё есть такой момент. Когда берутся за какой-то проект, то не имеют заранее всех нужных библиотек
Эта проблема может быть решена правильным алгоритмом планирования "от конца" , простой вариант алгоритма тут: https://pulsemanagement.org/rules-create-plan/ , полный в вариант в книге Детмера , называется "мыслительный процесс дерево перехода". Но... "это сложно". Хотя если нужно выполнить проект в срок то есть два пути: или планировать как выше указал или стандартизировать все операции и считать по функциональным точкам.
Главное его не только создать но и контролировать его расход. В этом случае можно шаг-за-шагом прийти к CCPM, потому что там и про размеры буферов есть и про их потребление и про их контроль.
Интересные решения! Мы тоже кастомные поля в json закатали. Но почему отдельной таблицей?
Про работу : с БД не понимаю зачем вы так любите хранимые процедуры (по примерам заметно) и желание писать на каждый чих новый запрос. Если ORM умеет что-то типа Linq (или иной конструктор SQL из кода), то можно иметь библиотеку запросов и фильтров/группировок/дополнений и создавать новые запросы дешево и быстро.
Например так: stm = strorage.stmSelect(); storage.addValidTasks( stm ); storage.addUserName( stm ); result = db.execute( stm );
Я лично от ручных запросов отказался еще в 2005 году.
Есть "Мы переехали с PHP на KPHP",
https://habr.com/ru/articles/686496/
ускорение точно есть и по опыту нагрузочных тестов - удешевление инфраструктуры.
Мы когда из интеграционных тестов небольшие скрипты через PHP-FPM дергали, то память расходовалась сильно. Добавили эти части в состав основного KPHP-сервера приложения - стало все идеально.
Можно и на С++ настолько плохо написать, что будут жраться ресурсы как не в себя. В 2004 году я переписывал счётчик HotLog (если кто-то помнит такой), Была производительность 100 хитов/секунду, стало 5000 хитов в секунду. Причина: применялась "копирка" c Perl с коллекциями (хеши). После рефакоринга на правильные типы данные и правильные коллекции (rbtree) скорость заметно выросла и количество необходимых серверов уменьшилось.
Есть KPHP - статическая типизация с "авто" выводом типов, и сборкой в нативный бинарник. (под капотом C++)
Совместимость с PHP обеспечивает быстрые проверки, а после сборки - быстрое исполнение.
Это генерённый текст? Уж больно много ошибок в понимании некоторых терминов.
Во первых, Скрам НЕ МЕТОДОЛОГИЯ! А процессный каркас, о чем прямо указано в Руководстве.
Во вторых, Скрам без XP для ИТ-проектов - что пиво без водки.
В третьих - Вы можете сколько угодно смотреть в трекер задач, но бизнес-человек хочет ПОСМОТРЕТЬ В ГЛАЗА и спросить "А не лапшу ли ты вешаешь, мил человек?" . Впрочем из истории Скрама именно эта практика и была вполне успешной (см. в книге Сазерленда) . Потому, что только сравнив план и факт можно задать вопрос глядя в глаза и нужные принять решения и относительно проекта и относительно людей в нём.
Вот так хорошо начал. Скрам плохо здесь, Скрам плохо там. Я подумал что, вот оно, сейчас приземлят на потребности бизнеса, и.... внезапно "Возьмите Канбан в нем нет оценок" я прямо осёкся.
Скрам отлично подходит для своей среды. Особенно, если вы не знаете куда идти. И особенно если Клиент не знает куда идти и какую цель достигать.
Но в RnD проектах ЕСТЬ ЦЕЛЬ. Просто часто непонятно "КАК её достигнуть". Ну так может сесть и подумать? Для этого даже специально обученные люди были.... как их там?... а вот вспомнил! Архитектор программного обеспечения!
А если вы не знаете куда идти, так может остановиться с просить Клиента, " А ты, вообще, какую проблему решаешь?"
Совещания здесь плохо, совещания там плохо. А ничего, что стандартного бизнес-человека беспокоит два вопроса:
1. Что происходит?
2. Когда будет готово?
И ему главное чтобы было: Сказал - сделал. Или выполняй обещания или не обещай. Правильные спринты Скрама дают эту прозрачность. Да и неправильные спринты тоже дают это. Только это называется "план-фактный анализ" и проводится каждую неделю. Часто никак даже не называется потому, что в понедельник нужно понять "Чем они будут заняты и почему я должен им платить?"
Продукты: A-Dato LYNX, Exepron, Pro Chain, BeingManagement3, BIPULSE. Из российских только BIPULSE. Обычные продукты CCPM не умеют, это специализированный софт только может.
Прошёл еще +1 год, в 2023 году появилась функция "Заполнить отчёт", чтобы быстро пробежаться по всем и указать какой физический объем выполнен и сколько дней еще нужно. Как раз для обзвона всех и отмечания прогресса.
Также мы завершили все работы с упаковкой в коробочную версию (вот буквально бинарник, на KPHP) и есть поставка на AstraLinux. И выпустили версию для рабочего стола "BIPULSE. АРМ Планировщик", как замену MS Project Pro.
За время пути собака смогла подрасти, вышел новый сервис АвтоГантт. По функциям - умеет выравнивать ресурсы и показывать плановую загрузку. Ресурсное планирование не в формате "сейчас укажем занятость 8-8-8-8-8 часов, а потом будем искать превышение", а "Вот на этих задачах у меня занят сотрудник, сделай мне магию, сдвинь задачи"
Там и вся книжка хорошая ;)
Точнее сказать оценка в часах годится только для "нормированной работы". Нормированная работа - работа для которой есть нормо-часы, как автосервисе, на стройке, на производстве.
Все верно! Только...
Час - это слишком точно для слишком неточной оценки
https://bipulse.ru/blog/index.php?post/2019/08/03/Как-оценивать-задачи
В последнее время я замечаю что вся непредсказуемость возникает из-за.... "Да ну нафиг оценивать в днях, давай в майках, или вообще не будем оценивать.". А потом начинаются попытки применить "процессы поддержки" где SLA есть и атомарность для основной разработки. И в итоге "статистика что-то не очень".
>Было бы любопытно посмотреть на ситуацию, когда контора получает лицензию на производство определённого ПО только при наличии заранее созданного набора инструментов.
Это называется "Сертификация компании по уровню CMMI", правда Мотороле это не очень помогло, но модель хорошая и понятная.
>А ещё есть такой момент. Когда берутся за какой-то проект, то не имеют заранее всех нужных библиотек
Эта проблема может быть решена правильным алгоритмом планирования "от конца" , простой вариант алгоритма тут: https://pulsemanagement.org/rules-create-plan/ , полный в вариант в книге Детмера , называется "мыслительный процесс дерево перехода". Но... "это сложно". Хотя если нужно выполнить проект в срок то есть два пути: или планировать как выше указал или стандартизировать все операции и считать по функциональным точкам.
Главное его не только создать но и контролировать его расход. В этом случае можно шаг-за-шагом прийти к CCPM, потому что там и про размеры буферов есть и про их потребление и про их контроль.
42% - Это почти стандартный размер буфера критической цепи. Там размер буфера - 50% длительности цепи.
Интересные решения!
Мы тоже кастомные поля в json закатали.
Но почему отдельной таблицей?
Про работу : с БД не понимаю зачем вы так любите хранимые процедуры (по примерам заметно) и желание писать на каждый чих новый запрос. Если ORM умеет что-то типа Linq (или иной конструктор SQL из кода), то можно иметь библиотеку запросов и фильтров/группировок/дополнений и создавать новые запросы дешево и быстро.
Например так:
stm = strorage.stmSelect();
storage.addValidTasks( stm );
storage.addUserName( stm );
result = db.execute( stm );
Я лично от ручных запросов отказался еще в 2005 году.
Если в задаче закладываете, то есть риск срабатывания закона Паркинсона.
Но по описанию вы готовы к переходу на следующий уровень: применение CCPM
.
Тогда нужна Методика (Метод управления проектным бизнесом, ISBN 978-5-0055-3024-0), чтобы план проекта был надёжным. Чтобы дыр не было.
Мне нравится формулировка "закладываем буфера", а контролируете ли их расход? ;)