Хороший обзор. Но рассказ про MRP, MRP II будет не полным, что с ростом сложности планирования появились ключевые логистические решения Теории ограничений - Барабан-Буфер-Канат
Прошло еще немного времени, вышло новое приложение (именно программа для рабочего стола для windows и Linux) ProjectLite https://ProjectLite.ru , как следует из названия, Это "лайт" версия планировщика. Умеет ключевые функции: строить график, отмечать фактические сроки. Совместим по формату хранения файлов с сервисом АвтоГант.
Поток проектов - нигде до этой Книги этого не был явно описан Голдратом в формате книги. Книга Критическая Цепь хорошо сфокусирована на ОДНОМ проекте. Но многопроектная среда имеет свои особенности. Поэтому и появилась такая книга.
Для управления проектами критической цепи, в том числе и по Потоку есть BIPULSE https://bipulse.ru/lp/ccpm
В России, только мы занимаемся внедрением CCPM и УП на основе CCPM (PulseManagement.org - книг, подкаст). Если будет нужен ответ "а как у нас это применить", заходите.
Хороший мануал! Появились вопросы: 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 разработчиков нет проблемы скорости и защиты - это не проблема самого решения.
Хороший обзор. Но рассказ про MRP, MRP II будет не полным, что с ростом сложности планирования появились ключевые логистические решения Теории ограничений - Барабан-Буфер-Канат
В статье почти полная история методов управления:
https://bipulse.ru/blog/index.php?post/2023/09/20/history-of-management-methods
Прошло еще немного времени, вышло новое приложение (именно программа для рабочего стола для windows и Linux) ProjectLite https://ProjectLite.ru , как следует из названия, Это "лайт" версия планировщика. Умеет ключевые функции: строить график, отмечать фактические сроки.
Совместим по формату хранения файлов с сервисом АвтоГант.
Поток проектов - нигде до этой Книги этого не был явно описан Голдратом в формате книги. Книга Критическая Цепь хорошо сфокусирована на ОДНОМ проекте. Но многопроектная среда имеет свои особенности. Поэтому и появилась такая книга.
Для управления проектами критической цепи, в том числе и по Потоку есть BIPULSE https://bipulse.ru/lp/ccpm
В России, только мы занимаемся внедрением CCPM и УП на основе CCPM (PulseManagement.org - книг, подкаст).
Если будет нужен ответ "а как у нас это применить", заходите.
Если в списке есть "Критическая Цепь" и "Правила Потока", то нужно добавить "Управление проектным бизнесом" Алексей Васильев ISBN 978-5-0055-3024-0
Это приземление CCPM на реальность для проектов НИОКР и ИТ.
Хороший мануал! Появились вопросы:
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 разработчиков нет проблемы скорости и защиты - это не проблема самого решения.