Хороший мануал! Появились вопросы: 1. Собираете ли вы из этой документации PDF? Если "да" то как? Кейс: если в комплекте поставки нужно чтобы "руководство пользователя" было в виде документа (со всеми колонтитулами). 2. Нужно ли было решать задачу разного именования каталога (категории) на файловой систем и в slug ?
любая система управления проектами строится вокруг канбан-доски.
Вокруг доски строится система управления ПОТОКОМ и операционной деятельностью.
Впрочем и не каждая доска является Канбан-доской.
У Проектов есть один отличный атрибут - ПЛАН и СРОК и их отслеживание. Нет Плана и Срока - нет проекта. Отличительной особенностью ИСУП - является график Ганта. Есть график - кладём в корзинку "ИСУП", нет графика - это командный задачник.
Все эти трекеры если и умеют Гант, то на уровне АвтоГанта (autogantt.ru) - то есть просто в виде картинки, часто не пригодной для управления, но её можно кому-то показать.
Правильный Гант - это хотя бы как в MS Project - работает как Эксель, есть базовый план, есть контроль отклонений от базового плана.
Если мы говорим об ИСУП (то есть про Управление Проектами), то для ИТ (аудитория Хабра), задачи которые есть в Ганте, это не те же самые задачи которые нужно делать. Но двухуровневное планирование это уже следующий уровень ИСУП. Это есть в BIPULSE (bipulse.ru).
Если мы говорим о контроле сроков: то ни один из представленных в статье трекеров задач не умеет делать прогнозирование сроков завершения проекта.
Из перечисленных только двое хоть как-то про управление проектами, остальные - управление задачами.
Нет в списке: BIPULSE, Plan-R , Spider project
Базовый критерий для управления проектом: контроль сроков проекта. Хоть как-то, хоть прогнозом, хоть Гантом. Если нет ни того не другого - это управление задачами, фирмой, процессами , продажами и тд.
Я так и не понял какой тезис хотели доказать. Но...
1. Критическая отлично работает, Embraer сделал новый самолёт за 3 года вместо 6. Пруфы на сайте Marris consulting и TOCICO.
2 вот это всё:
руководитель знает, сколько времени занимает каждый этап работы
сотрудники знают, как делать работу в срок
сотрудники знают, что делать, если они не успевают закончить работу в срок
срочные задачи не выбивают проект из колеи
и ещё много-много всего.
НЕ НУЖНО для старта работы по Критической Цепи и не нужно для "будет работать лучше" . Так, как ускорения работы есть типовой список вопросов и ритм контроля. Это описано в TOC Handbook, а также есть в книге "Управление проектным бизнесом".
Сотрудники вообще не хотят знать ничего про процессы, они хотят конструировать,писать код, проектировать, а не "вот это всё".
Руководитель также без понятия, сколько займёт времени работа. В стройке для этого есть "планировщики" , в ИТ - архитектор и инженеры, в производстве - технологические карты и нормирование.
Поэтому не надо придумывать, всё уже есть и описано. Например у Лоуренс Лича в "Вовремя и в рамках бюджета" или TOC Handbook. В Теории Ограничений не только Цепь есть, но и мыслительные процессы.
Поэтому:
Для планирования применяем "Дерево перехода" (ТОС) или "Алгоритм надежного планирования" (см. книгу "Управление проектным бизнесом").
Для выявления угроз применяем "Дерево будущей реальности" (ТОС) или "Соглашение о целях проекта" (см. книгу "Управление проектным бизнесом") или "Алгоритм надежного планирования, шаг 3".
Для ускорения работаем в Ритме и задаем вопросы: Когда закончишь? Почему не сейчас? (см TOC Handbook, "Управление проектным бизнесом" )
Также для выявления угроз и надежного плана выполняем оценку длительности работ "ковбойским методом" ("Управление проектным бизнесом").
А для того чтобы это все контролировать, и считать цепи есть BIPULSE.
У нас есть что-то из композера. И композер работает. и KPHP даже работает с PSR структурой файлов.
Про выражения - не понял вопроса. У нас не возникло никаких проблем с ними, и с лямбдами тоже, если Вы про них.
А вот eval() не положен по безопасности. Такое возможно только в интерпретаторах.
P.S. И с каких пор конструкции, полностью поддерживающиеся IDE, с работой автокомплита, с покрытием стат.анализатором, без каких либо инструментов метапрограммирования (get/set/call) и прочим называется "магией"?
В затягиваемых внешних библиотеках часто применяются магические методы. Если в Ваших фреймворках такого нет, и нет смены типа переменных "на лету", то такая библиотека может быть собрана в KPHP и Вы сможете получить преимущества от сборки в исполняемый платформозависимый файл.
Если Вам это не надо, нет проблем. Ниже Вы указали "Хочу узнать о переезде", я дал ссылку на статью про переезд без переезда.
У нас исторически свой ORM и свой роутер запросов. KPHP - Это просто другой рантайм. Если код написан без магии на рефлексии и с нормальной типизацией (как последние версии рекомендуют), то все собирается просто. Поэтому ничего не пришлось писать с нуля для миграции кроме обеспечения рефлексии (нужна для ORM). Для которых библиотек пришлось найти реализации на чистом PHP или подключить FFI.
Рантайм (как реализация исполнения языка и всех основных функций) не обязан обеспечивать поддержку монструозных платформ которые используют "магию". А PHP модули - у каждого рантайма свои. Я же не буду говорить "Ой, Mono не поддерживает WPF, это неправильная реализация, их язык только похож". Просто в реализации Mono нет этого модуля. Но с точки зрения реализации исполнения языка - всё хорошо.
KPHP вполне собирает код на PHP 7.4. И хотя есть свои дополнения, но они не мешают исполнению в PHP режиме.
Почему "подобие"? У нас приложение одинаково хорошо работает на PHP и KPHP. KPHP относится к PHP также, как Mono к .NET. Просто другой рантайм для такого же кода. Каких-то фич может и нет (рефлексия и что с ней связано), но это вопрос уровня поддержки рантаймом.
Если занять позицию "аналогов нет, и для быстрых сервисов давай менять язык", то конечно ничего не подойдёт. Нужна производительность но не хочется менять язык, то KPHP очень даже. К тому же разводить зоопарк языков на проекте так себе идея.
По ссылке https://habr.com/ru/articles/686496/ про "не существует". То, что у обычных PHP разработчиков нет проблемы скорости и защиты - это не проблема самого решения.
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 для ИТ-проектов - что пиво без водки.
В третьих - Вы можете сколько угодно смотреть в трекер задач, но бизнес-человек хочет ПОСМОТРЕТЬ В ГЛАЗА и спросить "А не лапшу ли ты вешаешь, мил человек?" . Впрочем из истории Скрама именно эта практика и была вполне успешной (см. в книге Сазерленда) . Потому, что только сравнив план и факт можно задать вопрос глядя в глаза и нужные принять решения и относительно проекта и относительно людей в нём.
Хороший мануал! Появились вопросы:
1. Собираете ли вы из этой документации PDF? Если "да" то как? Кейс: если в комплекте поставки нужно чтобы "руководство пользователя" было в виде документа (со всеми колонтитулами).
2. Нужно ли было решать задачу разного именования каталога (категории) на файловой систем и в slug ?
Это какой тип RAM? или это про сто-то другое?
Вопрос в том, если ли отслеживание отклонений по графику.
Вот уже в комментариях накинули, но тоже добавлю.
Вокруг доски строится система управления ПОТОКОМ и операционной деятельностью.
Впрочем и не каждая доска является Канбан-доской.
У Проектов есть один отличный атрибут - ПЛАН и СРОК и их отслеживание. Нет Плана и Срока - нет проекта. Отличительной особенностью ИСУП - является график Ганта. Есть график - кладём в корзинку "ИСУП", нет графика - это командный задачник.
Вот даже добавить нечего %))
Но базовое управление сроками даже на для Agile проектов должно же быть...
Все эти трекеры если и умеют Гант, то на уровне АвтоГанта (autogantt.ru) - то есть просто в виде картинки, часто не пригодной для управления, но её можно кому-то показать.
Правильный Гант - это хотя бы как в MS Project - работает как Эксель, есть базовый план, есть контроль отклонений от базового плана.
Если мы говорим об ИСУП (то есть про Управление Проектами), то для ИТ (аудитория Хабра), задачи которые есть в Ганте, это не те же самые задачи которые нужно делать. Но двухуровневное планирование это уже следующий уровень ИСУП.
Это есть в BIPULSE (bipulse.ru).
Если мы говорим о контроле сроков: то ни один из представленных в статье трекеров задач не умеет делать прогнозирование сроков завершения проекта.
Это про задачи, я говорю про проекты. Наличие поля "срок" еще ничего не говорит об инструментах его контроля.
Контроль сроков проектов или задач ? Для проектов примеры "по разному" в студию!
(Из перечисленных только двое: 1С:ПМ, Адванта - ИСУП)
Из перечисленных только двое хоть как-то про управление проектами, остальные - управление задачами.
Нет в списке: BIPULSE, Plan-R , Spider project
Базовый критерий для управления проектом: контроль сроков проекта.
Хоть как-то, хоть прогнозом, хоть Гантом.
Если нет ни того не другого - это управление задачами, фирмой, процессами , продажами и тд.
Я так и не понял какой тезис хотели доказать. Но...
1. Критическая отлично работает, Embraer сделал новый самолёт за 3 года вместо 6. Пруфы на сайте Marris consulting и TOCICO.
2 вот это всё:
НЕ НУЖНО для старта работы по Критической Цепи и не нужно для "будет работать лучше" . Так, как ускорения работы есть типовой список вопросов и ритм контроля. Это описано в TOC Handbook, а также есть в книге "Управление проектным бизнесом".
Сотрудники вообще не хотят знать ничего про процессы, они хотят конструировать,писать код, проектировать, а не "вот это всё".
Руководитель также без понятия, сколько займёт времени работа. В стройке для этого есть "планировщики" , в ИТ - архитектор и инженеры, в производстве - технологические карты и нормирование.
Поэтому не надо придумывать, всё уже есть и описано. Например у Лоуренс Лича в "Вовремя и в рамках бюджета" или TOC Handbook. В Теории Ограничений не только Цепь есть, но и мыслительные процессы.
Поэтому:
Для планирования применяем "Дерево перехода" (ТОС) или "Алгоритм надежного планирования" (см. книгу "Управление проектным бизнесом").
Для выявления угроз применяем "Дерево будущей реальности" (ТОС) или "Соглашение о целях проекта" (см. книгу "Управление проектным бизнесом") или "Алгоритм надежного планирования, шаг 3".
Для ускорения работаем в Ритме и задаем вопросы: Когда закончишь? Почему не сейчас? (см TOC Handbook, "Управление проектным бизнесом" )
Также для выявления угроз и надежного плана выполняем оценку длительности работ "ковбойским методом" ("Управление проектным бизнесом").
А для того чтобы это все контролировать, и считать цепи есть BIPULSE.
https://vkcom.github.io/kphp/kphp-language/best-practices/async-programming-forks.html
Корутины вроде как есть. Но компилируемый PHP в варианте KPHP накладывает еще и жесткую типизацию.
У нас есть что-то из композера. И композер работает. и KPHP даже работает с PSR структурой файлов.
Про выражения - не понял вопроса. У нас не возникло никаких проблем с ними, и с лямбдами тоже, если Вы про них.
А вот eval() не положен по безопасности. Такое возможно только в интерпретаторах.
В затягиваемых внешних библиотеках часто применяются магические методы. Если в Ваших фреймворках такого нет, и нет смены типа переменных "на лету", то такая библиотека может быть собрана в KPHP и Вы сможете получить преимущества от сборки в исполняемый платформозависимый файл.
Если Вам это не надо, нет проблем. Ниже Вы указали "Хочу узнать о переезде", я дал ссылку на статью про переезд без переезда.
У нас исторически свой ORM и свой роутер запросов.
KPHP - Это просто другой рантайм. Если код написан без магии на рефлексии и с нормальной типизацией (как последние версии рекомендуют), то все собирается просто. Поэтому ничего не пришлось писать с нуля для миграции кроме обеспечения рефлексии (нужна для ORM). Для которых библиотек пришлось найти реализации на чистом PHP или подключить FFI.
Рантайм (как реализация исполнения языка и всех основных функций) не обязан обеспечивать поддержку монструозных платформ которые используют "магию".
А PHP модули - у каждого рантайма свои. Я же не буду говорить "Ой, Mono не поддерживает WPF, это не правильная реализация, их язык только похож". Просто в реализации Mono нет этого модуля. Но с точки зрения реализации исполнения языка - всё хорошо.
KPHP вполне собирает код на PHP 7.4.
И хотя есть свои дополнения, но они не мешают исполнению в PHP режиме.
Почему "подобие"? У нас приложение одинаково хорошо работает на PHP и KPHP. KPHP относится к PHP также, как Mono к .NET. Просто другой рантайм для такого же кода.
Каких-то фич может и нет (рефлексия и что с ней связано), но это вопрос уровня поддержки рантаймом.
Если занять позицию "аналогов нет, и для быстрых сервисов давай менять язык", то конечно ничего не подойдёт. Нужна производительность но не хочется менять язык, то KPHP очень даже.
К тому же разводить зоопарк языков на проекте так себе идея.
По ссылке https://habr.com/ru/articles/686496/ про "не существует".
То, что у обычных PHP разработчиков нет проблемы скорости и защиты - это не проблема самого решения.
Есть "Мы переехали с PHP на KPHP",
https://habr.com/ru/articles/686496/
ускорение точно есть и по опыту нагрузочных тестов - удешевление инфраструктуры.
Мы когда из интеграционных тестов небольшие скрипты через PHP-FPM дергали, то память расходовалась сильно. Добавили эти части в состав основного KPHP-сервера приложения - стало все идеально.
Можно и на С++ настолько плохо написать, что будут жраться ресурсы как не в себя. В 2004 году я переписывал счётчик HotLog (если кто-то помнит такой), Была производительность 100 хитов/секунду, стало 5000 хитов в секунду. Причина: применялась "копирка" c Perl с коллекциями (хеши). После рефакоринга на правильные типы данные и правильные коллекции (rbtree) скорость заметно выросла и количество необходимых серверов уменьшилось.
Есть KPHP - статическая типизация с "авто" выводом типов, и сборкой в нативный бинарник. (под капотом C++)
Совместимость с PHP обеспечивает быстрые проверки, а после сборки - быстрое исполнение.
Это генерённый текст? Уж больно много ошибок в понимании некоторых терминов.
Во первых, Скрам НЕ МЕТОДОЛОГИЯ! А процессный каркас, о чем прямо указано в Руководстве.
Во вторых, Скрам без XP для ИТ-проектов - что пиво без водки.
В третьих - Вы можете сколько угодно смотреть в трекер задач, но бизнес-человек хочет ПОСМОТРЕТЬ В ГЛАЗА и спросить "А не лапшу ли ты вешаешь, мил человек?" . Впрочем из истории Скрама именно эта практика и была вполне успешной (см. в книге Сазерленда) . Потому, что только сравнив план и факт можно задать вопрос глядя в глаза и нужные принять решения и относительно проекта и относительно людей в нём.