Эта зверюга, 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 Шаг: Определить цель системы.
Если Цель системы - выкатывать больше изменений в единицу времени - то это хорошая тема для обсуждения. (Но так ли это?)
А что если я скажу, что есть решение которое решает все сложности календарного планирования проекта и перепланирования проекта, учитывает неопределённость оценок и интегрируется с Jira/YouTrack и другими трекерами без необходимости ручного перегона задач туда-сюда?
А понял! Если мы говорим про «монтажников», у которых только мобильник. то сейчас в BIPULSE есть возможность зарезать интерфейс в профиле «исполнитель» по максимуму. Но без реального Клиента с такой областью применения приоритет реализации такой функции весьма туманен %(
Благодарю за комплимент! Над эргономикой мы работаем, но ключевое для нас: готов ли Клиент использовать BIPULSE для решения своих задач. Если использует, то на основе обратной связи мы адаптируем интерфейс. После смены frontend движка у нас появилось много возможностей по калибровке.
Из недавних примеров изменений на основе запроса: добавили опцию режима ручного планирования задач и задание режима расчета буфера чисто по CCPM и его размера вместо «адаптивного» по Pulse Management.
>> циркулярный опрос команды «сколько осталось времени до завершения твоей текущей задачи?».
1. Собираем всех на «летучку»
2. Открываем «План / Оперативный / Задачи в работе» (там все факты есть сколько потратили времени и сколько хотели)
3. Идем по каждой задаче и задаём вопросы.
Если команда работает асинхронно и проект идет по CCPM (важно), и «летучку » не провести, то:
1. У исполнителя как правило есть своя задача «в работе» и карточка на неё уже открыта
2. Он тыкает в «осталось дней» и вводит значение +таб. Всё.
3. Мы на План/Тактический видим отклонение проекта.
Но этот метод плох тем, что мы не можем ускорить исполнение «в моменте». Так как на живой вопрос, мы получаем живой ответ и можем сразу предпринять корректирующие действия. Я соглашусь что дополнительный робот-пинатель будет хорошо, но его отсутствие пока это ни разу не являлось препятствием к внедрению.
>>Люди и так сопротивляются изменению устоявшейся практики, а тут вы им вгружаете дополнительные не самые простые инструменты…
Классное замечание! Мы это в версии 7.0, которая вышла в апреле этого года, преодолели! И теперь для исполнителей есть профили «исполнитель» — для тех кто «могу копать, могу не копать» и «инженер» — доски, списки задач и целей. А все стальное только для руководителя
Кирилл, со сравнению с 2017 годом, сейчас BIPULSE — почти не имеет проблем, однако для эффективного применения требует использования Метода управления «Pulse Management» pulsemanagement.org (цикл публикаций на Хабре habr.com/ru/post/462423)
Метод учитывает особенности применения CCPM для «реальной жизни» ИТ-проектов.
Проблема внедрения CCPM не в софте, а в головах. Так как требуется перестройка способа мышления и принятия решений.
Метод базируется на ТОС, и я об этом написал в самом начале цикла публикаций habr.com/ru/post/462423, но в CCPM есть ряд ложных предпосылок для среды с высокой неопределенностью. Так же CCPM не закрывает все аспекты управления проектами.
1. ТОС — это не только про узкое место, это еще и системные инструменты анализа и решения ситуации.
2. >> Не знаю, где Вы взяли данные о том,
Статистика TOCICO, CCPM — это только один из инструментов общего процесса. В одной из компаний которую мы консультировали, сокращение одновременных исполняющихся проектов (проектов, но не контрактов) с 30 до 8 заняло полгода.
Если Ваша позиция в том чтобы отрывать головы вместо решения задачи о возвращении проекта в норму — это ваше право. Возможно у Вас неограниченные ресурсы и бюджет для таких действий, чтобы восполнить оторванную голову новой. Однако, моя практика показывает, что владелец компании меняет свои привычки для того, чтобы обеспечить выполнение всех обязательств организации вовремя и в полном объеме.
Результат применения Метода один: Выполнение Организацией всех обязательств вовремя и в полном объеме. Если вы уже применили Метод и не получили этот результат, то нужно разбираться как вам это удалось. Статистика TOCICO — 90% проектов применяющих Критическую Цепь завершаются вовремя, Метод определяет правила игры с применением инструментов ТОС, Agile и проектного управления.
Границы применения Метода и его полнота опубликована в первой статье.
о ГОСТах: ГОСТы вещь хорошая, однако:
1. Они определяют правила, но не говорят «зачем так»
2. Их мало кто читает, если это не прописано в ТЗ к контракту.
Метод Пульса (Pulse Management) решает эти два препятствия за счёт компактности практик и цельного подхода для цикла PCDA
1. Какое влияние по Вашему мнению может оказывать доминирующая вершина на остальные?
2. Определение Пульса — в следующей публикации про инструменты Метода.
3. О потоках. Хороший вопрос! Поток — не процесс, это поток мышления. Состояние в которым мы думаем. Я раскрою эту главу лучше.
4. О «Чем отличается» Можете ли привести в процентах количество инженеров-конструкторов, инженеров-проектировщиков, инженеров-программистов (от всех) которые прочитали теорию управления производственным предприятием? Можете ли при вести в процентах количество менеджеров проектов и отделов которые прочитали приложение к PMBoK про управление программами и портфелями?
5. Как взаимодействуют: описано в методичке которая лежит на pulsemanagement.org или расскажу в последующих публикациях.
Если бы время не было ограничено, можно было бы развивать все потоки и не париться.
Верно!
Но Метод базируется на том что ресурсы ограничены. (позже опубликую эти части на Хабре). Но не учитывает их в модели организации.
Ограничение всегда есть. И хорошо, чтобы оно было внутри Организации а не снаружи. Но это уже вопросы ТОС. Метод формализует только одно из применений ТОС — управление проектной организацией, управление портфелем проектов.
Модель организации — не проектный треугольник. Организация развивается в трёх направлениях.
1. Развитие Организации в направлении «Технологии» идёт когда сотрудник работает в Потоке Реализации или Управления, при этом развитие Организации в направлении Правил и процессов происходит когда сотрудник работает в Потоке Улучшений.
Все действия в Потоке Управления это принятие решений в соответствии с Правилами.
Фокус внимания в каждом потоке на разных вещах, как и инициатор изменений:
— Цели — владелец компании, продажи.
— Правила и процессы — методолог, хозяин процесса-Scrum, Владелец процесса
— Технологии и профессионализм — технолог, архитектор, руководитель отдела
2. Я не вижу такого направления развития Организации как «Ресурсы». Организация может работать вообще без ресурсов, а покупать их на стороне и при этом нормально зарабатывать деньги. Однако, обладая Технологиями мы можем создавать новые продукты или услуги. А поднимая профессионализм мы можем улучшать технологии. Но это всё не поможет, если мы не обращаем внимания на способ работы. Именно на развитие этого направления и отвечает ось «Правила».
Перед тем, как подискутировать, я предлагаю уточнить границы:
Метод не является полным руководством по управлению компанией.
Метод не является сводом знаний (BOK) по управлению компанией.
Метод описывает способ организации работ в проектной организацией.
Метод может стыковаться с любыми другими практиками, которые обеспечивают реакцию на все предпосылки на которых базируются Правила Метода.
Есть «авторское право» которое неотторжимо в силу закона, и есть имущественные права. Всякие «право на распространение» и т.д. Передать можно только имущественные права.
В трудовом договоре обычно прописано о переходе имущественных прав созданное произведение, с указанием при каких условиях оно создано.: «всё что создается по поручению работодателя и при выполнении должностных обязанностей». В контракте на заказную разработку явно указывается о передаче имущественных прав.
Таким образом все регламентируется и вполне прозрачно.
Эта зверюга, 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 Шаг: Определить цель системы.
Если Цель системы - выкатывать больше изменений в единицу времени - то это хорошая тема для обсуждения. (Но так ли это?)
А что если я скажу, что есть решение которое решает все сложности календарного планирования проекта и перепланирования проекта, учитывает неопределённость оценок и интегрируется с Jira/YouTrack и другими трекерами без необходимости ручного перегона задач туда-сюда?
Из недавних примеров изменений на основе запроса: добавили опцию режима ручного планирования задач и задание режима расчета буфера чисто по CCPM и его размера вместо «адаптивного» по Pulse Management.
1. Собираем всех на «летучку»
2. Открываем «План / Оперативный / Задачи в работе» (там все факты есть сколько потратили времени и сколько хотели)
3. Идем по каждой задаче и задаём вопросы.
Если команда работает асинхронно и проект идет по CCPM (важно), и «летучку » не провести, то:
1. У исполнителя как правило есть своя задача «в работе» и карточка на неё уже открыта
2. Он тыкает в «осталось дней» и вводит значение +таб. Всё.
3. Мы на План/Тактический видим отклонение проекта.
Но этот метод плох тем, что мы не можем ускорить исполнение «в моменте». Так как на живой вопрос, мы получаем живой ответ и можем сразу предпринять корректирующие действия. Я соглашусь что дополнительный робот-пинатель будет хорошо, но его отсутствие пока это ни разу не являлось препятствием к внедрению.
>>Люди и так сопротивляются изменению устоявшейся практики, а тут вы им вгружаете дополнительные не самые простые инструменты…
Классное замечание! Мы это в версии 7.0, которая вышла в апреле этого года, преодолели! И теперь для исполнителей есть профили «исполнитель» — для тех кто «могу копать, могу не копать» и «инженер» — доски, списки задач и целей. А все стальное только для руководителя
Кирилл, со сравнению с 2017 годом, сейчас BIPULSE — почти не имеет проблем, однако для эффективного применения требует использования Метода управления «Pulse Management» pulsemanagement.org (цикл публикаций на Хабре habr.com/ru/post/462423)
Метод учитывает особенности применения CCPM для «реальной жизни» ИТ-проектов.
Проблема внедрения CCPM не в софте, а в головах. Так как требуется перестройка способа мышления и принятия решений.
2. >> Не знаю, где Вы взяли данные о том,
Статистика TOCICO, CCPM — это только один из инструментов общего процесса. В одной из компаний которую мы консультировали, сокращение одновременных исполняющихся проектов (проектов, но не контрактов) с 30 до 8 заняло полгода.
Если Ваша позиция в том чтобы отрывать головы вместо решения задачи о возвращении проекта в норму — это ваше право. Возможно у Вас неограниченные ресурсы и бюджет для таких действий, чтобы восполнить оторванную голову новой. Однако, моя практика показывает, что владелец компании меняет свои привычки для того, чтобы обеспечить выполнение всех обязательств организации вовремя и в полном объеме.
Результат применения Метода один: Выполнение Организацией всех обязательств вовремя и в полном объеме. Если вы уже применили Метод и не получили этот результат, то нужно разбираться как вам это удалось. Статистика TOCICO — 90% проектов применяющих Критическую Цепь завершаются вовремя, Метод определяет правила игры с применением инструментов ТОС, Agile и проектного управления.
Границы применения Метода и его полнота опубликована в первой статье.
о ГОСТах: ГОСТы вещь хорошая, однако:
1. Они определяют правила, но не говорят «зачем так»
2. Их мало кто читает, если это не прописано в ТЗ к контракту.
Метод Пульса (Pulse Management) решает эти два препятствия за счёт компактности практик и цельного подхода для цикла PCDA
2. Определение Пульса — в следующей публикации про инструменты Метода.
3. О потоках. Хороший вопрос! Поток — не процесс, это поток мышления. Состояние в которым мы думаем. Я раскрою эту главу лучше.
4. О «Чем отличается» Можете ли привести в процентах количество инженеров-конструкторов, инженеров-проектировщиков, инженеров-программистов (от всех) которые прочитали теорию управления производственным предприятием? Можете ли при вести в процентах количество менеджеров проектов и отделов которые прочитали приложение к PMBoK про управление программами и портфелями?
5. Как взаимодействуют: описано в методичке которая лежит на pulsemanagement.org или расскажу в последующих публикациях.
Верно!
Но Метод базируется на том что ресурсы ограничены. (позже опубликую эти части на Хабре). Но не учитывает их в модели организации.
Ограничение всегда есть. И хорошо, чтобы оно было внутри Организации а не снаружи. Но это уже вопросы ТОС. Метод формализует только одно из применений ТОС — управление проектной организацией, управление портфелем проектов.
1. Развитие Организации в направлении «Технологии» идёт когда сотрудник работает в Потоке Реализации или Управления, при этом развитие Организации в направлении Правил и процессов происходит когда сотрудник работает в Потоке Улучшений.
Все действия в Потоке Управления это принятие решений в соответствии с Правилами.
Фокус внимания в каждом потоке на разных вещах, как и инициатор изменений:
— Цели — владелец компании, продажи.
— Правила и процессы — методолог, хозяин процесса-Scrum, Владелец процесса
— Технологии и профессионализм — технолог, архитектор, руководитель отдела
2. Я не вижу такого направления развития Организации как «Ресурсы». Организация может работать вообще без ресурсов, а покупать их на стороне и при этом нормально зарабатывать деньги. Однако, обладая Технологиями мы можем создавать новые продукты или услуги. А поднимая профессионализм мы можем улучшать технологии. Но это всё не поможет, если мы не обращаем внимания на способ работы. Именно на развитие этого направления и отвечает ось «Правила».
Перед тем, как подискутировать, я предлагаю уточнить границы:
А именно:
Глоссарий: pulsemanagement.org/glossary
В трудовом договоре обычно прописано о переходе имущественных прав созданное произведение, с указанием при каких условиях оно создано.: «всё что создается по поручению работодателя и при выполнении должностных обязанностей». В контракте на заказную разработку явно указывается о передаче имущественных прав.
Таким образом все регламентируется и вполне прозрачно.