Forwarded from 401 Unauthorized: аутентификация и не только (Andrey Kuznetsov)
[1/2] Вторая часть обзора книги “Cloud Native Data Security with OAuth”
Продолжаю писать про данную книгу. Также напомню, что ее можно получить бесплатно.
Вторую часть книги авторы посвящают использованию токенов для обеспечения безопасности API и начинают с главы 5 - «Secure API Development».
Авторам нравится идея, когда конечные сервисы работают только с self-contained, JWT токеном доступа (мне такая идея тоже нравится, кстати), а сами clients могут использовать другие, различные временные учетные данные.
Говорят про валидацию JWT, затрагивают проверку подписи и ротацию ключей. Также отмечают, что лучше не забывать про тесты с невалидными JWT, чтобы иметь уверенность, что валидация работает, как надо.
Авторы отделяют проверку JWT от самой проверки авторизации, и далее как раз пишут и про нее. Например, упоминают о возможности использования scopes для «грубой» (coarse) проверки авторизации. При этом пишут, что scopes могут помочь задать некоторые «границы» применения токена, но не предоставляют, естественно, сами по себе полного решения задач проверки авторизации.
В контексте обработки истечения времени жизни токенов говорят про «короткое» время жизни токенов доступа, отмечая, что такие токены живут меньше, чем «users’ sessions». Это любопытно, потому что я как раз таким же образом выводил определение короткого времени жизни в докладе “Refresh token в веб-приложениях: быть или не быть?” (надеюсь, скоро доберусь опубликовать материал в виде статьи).
Переходят к вопросам тестирования. Предлагают подход разделения самого JWT и уже того, что называют «claims principal object» - как модельку уже. Из этого исходит идея, что можно тогда покрывать логику проверки авторизации юнит-тестами, используя в качестве фикстуры различные вариации этого «claims principal object».
Также рассказывают, как можно имитировать OAuth-обвязку для тестирования работы конечного сервиса: создать свою ключевую пару, замокать JWKS URI и настроить сервис на работу с ним. Тогда с приватным ключом из ключевой пары можно наподписывать себе любых токенов, что как раз удобно для различных тестов. Ну и с таким подходом, соответственно, поощряют разработчиков к более частому и легкому запуску тестов изолированно, локально – без необходимости поднимать какие-то еще сервисы для обвязки.
Дальше авторы переходят к вопросам проектирования и использования самих access tokens. Предлагают рассматривать access token как контракт, причем даже если он является непрозрачным (opaque), потому что, например, увеличив длину токена, можно тоже поломать чью-нибудь работу.
Пишут, что scopes не являются полным решением для [проверки] авторизации, однако они как раз формируют область действия для токена (я бы сюда еще добавил и audiences). Соответственно авторы тоже говорят о том, что используя скоупы client может получить access token для конкретных целей, ну и что их всегда стоит ограничивать.
Пишут авторы и про дизайн скоупов, при этом предлагают проектировать их исходя из понятий бизнесовых, нежели чем из технических. И дают совет: можно как источник вдохновения при дизайне скоупов посмотреть, как это сделано в спецификации OIDC.
Упоминая claims, напоминают, что помещая их в токен, authorization server как бы “ручается” за их содержимое, и конечные сервисы будут им доверять. Поэтому важно не помещать непроверенную информацию в содержимое клˈеймов.
Говорят про различные источники данных для клеймов, отмечают и факт, что часто меняющиеся значения не являются хорошими кандидатами на помещение в claims, потому что могут быстро стать неактуальными.
Также в этой главе авторы приводят определенный подход к дизайну scopes и claims, в том числе с учетом дальнейшей эксплуатации и масштабирования.
Затрагивают такую тему, как передача, распространение токенов (token sharing). Кратко разбирают такие подходы, как token exchange и embedding tokens in tokens. Упоминают и про использование токенов доступа при асинхронных операциях: что делать, когда проверка токена может произойти значительно позже отправки сообщения с ним.
(продолжение см. ниже)
#book #iam_general #oauth.
Продолжаю писать про данную книгу. Также напомню, что ее можно получить бесплатно.
Вторую часть книги авторы посвящают использованию токенов для обеспечения безопасности API и начинают с главы 5 - «Secure API Development».
Авторам нравится идея, когда конечные сервисы работают только с self-contained, JWT токеном доступа (мне такая идея тоже нравится, кстати), а сами clients могут использовать другие, различные временные учетные данные.
Говорят про валидацию JWT, затрагивают проверку подписи и ротацию ключей. Также отмечают, что лучше не забывать про тесты с невалидными JWT, чтобы иметь уверенность, что валидация работает, как надо.
Авторы отделяют проверку JWT от самой проверки авторизации, и далее как раз пишут и про нее. Например, упоминают о возможности использования scopes для «грубой» (coarse) проверки авторизации. При этом пишут, что scopes могут помочь задать некоторые «границы» применения токена, но не предоставляют, естественно, сами по себе полного решения задач проверки авторизации.
В контексте обработки истечения времени жизни токенов говорят про «короткое» время жизни токенов доступа, отмечая, что такие токены живут меньше, чем «users’ sessions». Это любопытно, потому что я как раз таким же образом выводил определение короткого времени жизни в докладе “Refresh token в веб-приложениях: быть или не быть?” (надеюсь, скоро доберусь опубликовать материал в виде статьи).
Переходят к вопросам тестирования. Предлагают подход разделения самого JWT и уже того, что называют «claims principal object» - как модельку уже. Из этого исходит идея, что можно тогда покрывать логику проверки авторизации юнит-тестами, используя в качестве фикстуры различные вариации этого «claims principal object».
Также рассказывают, как можно имитировать OAuth-обвязку для тестирования работы конечного сервиса: создать свою ключевую пару, замокать JWKS URI и настроить сервис на работу с ним. Тогда с приватным ключом из ключевой пары можно наподписывать себе любых токенов, что как раз удобно для различных тестов. Ну и с таким подходом, соответственно, поощряют разработчиков к более частому и легкому запуску тестов изолированно, локально – без необходимости поднимать какие-то еще сервисы для обвязки.
Дальше авторы переходят к вопросам проектирования и использования самих access tokens. Предлагают рассматривать access token как контракт, причем даже если он является непрозрачным (opaque), потому что, например, увеличив длину токена, можно тоже поломать чью-нибудь работу.
Пишут, что scopes не являются полным решением для [проверки] авторизации, однако они как раз формируют область действия для токена (я бы сюда еще добавил и audiences). Соответственно авторы тоже говорят о том, что используя скоупы client может получить access token для конкретных целей, ну и что их всегда стоит ограничивать.
Пишут авторы и про дизайн скоупов, при этом предлагают проектировать их исходя из понятий бизнесовых, нежели чем из технических. И дают совет: можно как источник вдохновения при дизайне скоупов посмотреть, как это сделано в спецификации OIDC.
Упоминая claims, напоминают, что помещая их в токен, authorization server как бы “ручается” за их содержимое, и конечные сервисы будут им доверять. Поэтому важно не помещать непроверенную информацию в содержимое клˈеймов.
Говорят про различные источники данных для клеймов, отмечают и факт, что часто меняющиеся значения не являются хорошими кандидатами на помещение в claims, потому что могут быстро стать неактуальными.
Также в этой главе авторы приводят определенный подход к дизайну scopes и claims, в том числе с учетом дальнейшей эксплуатации и масштабирования.
Затрагивают такую тему, как передача, распространение токенов (token sharing). Кратко разбирают такие подходы, как token exchange и embedding tokens in tokens. Упоминают и про использование токенов доступа при асинхронных операциях: что делать, когда проверка токена может произойти значительно позже отправки сообщения с ним.
(продолжение см. ниже)
#book #iam_general #oauth.
❤1👍1🔥1
Forwarded from 401 Unauthorized: аутентификация и не только (Andrey Kuznetsov)
[2/2] Вторая часть обзора книги “Cloud Native Data Security with OAuth”
Далее переходят к вопросам безопасного использования токенов доступа. Один из авторов, Michal Trojanowski, кстати, ранее так и писал в одной из своих статей:
Авторы пишут про различные форматы токенов доступа и про работу с ними: интроспекция, token exchange, the split token pattern.
Говоря про разные подходы, которыми можно обезопасить токены доступа, упоминают и подход ограничения их области действия до минимально необходимой - то, о чем нам говорит принцип least privilege.
Затем авторы решают рассказать про использование API Gateway и service mesh. Приводят краткую справку, как и что устроено в контексте Kubernetes, упоминая про Ingress и Gateway API.
Авторы пишут, что на их взгляд, ключевым фактором при выборе API Gateway является расширяемость, подводя к дальнейшему рассмотрению работы с токенами доступа, того что называют “token termination”.
Такая token termination в видении авторов состоит из двух задач:
🔵 валидация входящих временных учетных данных
🔵 трансляция их в JWT access token для конечных сервисов.
А дальше авторы как раз разбираю эти задачи для непрозрачных токенов доступа, cookies и sender-constrained токенов.
Говорится:
В конце главы читателя ждет небольшой пример использования API Gateway (авторы используют Kong) в Kubernetes. Также здесь авторы демонстрируют пример использования ранее упомянутой расширяемости: пишут плагин на Lua, чтобы реализовать схему с двумя видами токенов доступа (как они это называют - the Phantom Token Approach).
На протяжении данной главы авторы на это несколько раз намекали, а здесь уже прямо показывают, что реализовывать такую схему они предлагают через RFC 9701 JSON Web Token (JWT) Response for OAuth Token Introspection. Однако мне не очень нравится использование данного RFC для решения обозначенной задачи:
🔵 Здесь получаете не отдельный токен доступа в виде JWT, а обернутый в JWT тот же ответ от introspection endpoint
🔵 Таким образом два представления токена доступа полноценно не “развязать”: полученный JWT не ограничить отдельно по времени жизни или области действия
🔵 Сами авторы RFC пишут, что возвращаемый здесь JWT “is not an alternative representation of the introspected access token and is not intended to be used as an access token”
В девятой главе авторы переходят к рассмотрению вопросов контроля доступа. Рассматривают кратко такие модели контроля доступа, как RBAC, ReBAC, ABAC (а еще упоминают понятие RAdAC).
Понравилось высказывание о том, что недостаточно только лишь хорошо продумать правила доступа, важно не упускать из фокуса и процесс наделения субъектов полномочиями (например, назначение ролей пользователям). Таким образом подчеркивают, что нужно стараться не допускать “overprivileged accounts”.
Интересна и часть, где авторы описывают преимущества использования выделенной ennoscriptment management system (EMS):
🔵 Flexibility (API работают только с предоставленным результатом, саму логику контроля доступа можно изменять, не ломая их)
🔵 Auditability (имеем события аудита как для применения политик, так и их для изменения)
🔵 Security agility (отделение ЖЦ политик доступа от ЖЦ конечных сервисов)
🔵 Quality assurance via policy as code (если политики прописываются отдельно, сами сервисы могут не тестировать их внутреннюю логику, а покрывать только возможные исходы)
В завершение кратко упоминают про P*P-концепцию и рассказывают про использования Open Policy Agent (OPA), заодно показывая небольшой пример использования языка Rego.
#book #iam_general #oauth.
Далее переходят к вопросам безопасного использования токенов доступа. Один из авторов, Michal Trojanowski, кстати, ранее так и писал в одной из своих статей:
While secure flows are essential, they should be complemented by a keen focus on access tokens.
Авторы пишут про различные форматы токенов доступа и про работу с ними: интроспекция, token exchange, the split token pattern.
Говоря про разные подходы, которыми можно обезопасить токены доступа, упоминают и подход ограничения их области действия до минимально необходимой - то, о чем нам говорит принцип least privilege.
Затем авторы решают рассказать про использование API Gateway и service mesh. Приводят краткую справку, как и что устроено в контексте Kubernetes, упоминая про Ingress и Gateway API.
Авторы пишут, что на их взгляд, ключевым фактором при выборе API Gateway является расширяемость, подводя к дальнейшему рассмотрению работы с токенами доступа, того что называют “token termination”.
Такая token termination в видении авторов состоит из двух задач:
А дальше авторы как раз разбираю эти задачи для непрозрачных токенов доступа, cookies и sender-constrained токенов.
Говорится:
We have seen that your overall API security is distributed between the API gateway APIs, and possibly additional components such as service meshes.
В конце главы читателя ждет небольшой пример использования API Gateway (авторы используют Kong) в Kubernetes. Также здесь авторы демонстрируют пример использования ранее упомянутой расширяемости: пишут плагин на Lua, чтобы реализовать схему с двумя видами токенов доступа (как они это называют - the Phantom Token Approach).
На протяжении данной главы авторы на это несколько раз намекали, а здесь уже прямо показывают, что реализовывать такую схему они предлагают через RFC 9701 JSON Web Token (JWT) Response for OAuth Token Introspection. Однако мне не очень нравится использование данного RFC для решения обозначенной задачи:
В девятой главе авторы переходят к рассмотрению вопросов контроля доступа. Рассматривают кратко такие модели контроля доступа, как RBAC, ReBAC, ABAC (а еще упоминают понятие RAdAC).
Понравилось высказывание о том, что недостаточно только лишь хорошо продумать правила доступа, важно не упускать из фокуса и процесс наделения субъектов полномочиями (например, назначение ролей пользователям). Таким образом подчеркивают, что нужно стараться не допускать “overprivileged accounts”.
Интересна и часть, где авторы описывают преимущества использования выделенной ennoscriptment management system (EMS):
В завершение кратко упоминают про P*P-концепцию и рассказывают про использования Open Policy Agent (OPA), заодно показывая небольшой пример использования языка Rego.
#book #iam_general #oauth.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2❤1🔥1
Forwarded from Архитектура ИТ-решений
Когда речь заходит о записях архитектурных решений (architecture decision records, ADR) часто возникает вопрос: где посмотреть реальный пример? Вот чтоб в проекте более-менее долго фиксировались решения, уточнялись, пересматривались и т.п.
... и тут все обычно начинают мяться, вспоминают про NDA
Из открытых проектов я бы предложил посмотреть как это ведется в NATS, см. NATS Architecture And Design Если у кого-то есть еще примеры, то непременно поделитесь, плз.
... и тут все обычно начинают мяться, вспоминают про NDA
Из открытых проектов я бы предложил посмотреть как это ведется в NATS, см. NATS Architecture And Design Если у кого-то есть еще примеры, то непременно поделитесь, плз.
GitHub
GitHub - nats-io/nats-architecture-and-design: Architecture and Design Docs
Architecture and Design Docs . Contribute to nats-io/nats-architecture-and-design development by creating an account on GitHub.
❤7👍2🔥2
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
В предыдущем посте говорилось, что pessimistic scenario не совсем корректен в Taskjuggler. Картинка демонстрирует, как должны быть сложены две оценки. Мы видим, что оценки пересекаются. Вот почему мы должны сложить отдельно вероятностную оценку и среднеквадратичное…
Немного модифицировал JIRA to TaskJuggler convertor ( https://github.com/emacsway/jira-juggler ), чтобы он сохранял иерархию Epic -> UserStory -> Task. Удобно для извлечения и планирования эпика целиком.
GitHub
GitHub - emacsway/jira-juggler: JIRA to TaskJuggler convertor
JIRA to TaskJuggler convertor. Contribute to emacsway/jira-juggler development by creating an account on GitHub.
👍1🔥1🙏1
Forwarded from Системный сдвиг
Рассказывая про атрибуты качества, я раньше приводил в пример страницу из Википедии, их тут перечисленно 92 штуки.
Иногда выводил из на один слайд, получается впечатляюще.
Но теперь я нашел ещё более ужасающую картинку.
Это граф, в котором перечислено 162(!) атрибута качества и 104 примера требований, связанных с этим ограничениями. У каждого атрибута есть описание, то есть это не просто картинка, а целая энциклопедия (на английском).
Кажется, это исчерпывающий каталог атрибутов качества, куда уж больше.
Основа тут - восемь главных областей. Система должна быть:
- Надежной (Reliable)
- Безопасной (Safe), иногда переводят "свободной от неприемлемых рисков" - никого не убьет и не обанкротит, ничего не разрушит
- Защищенной (Secure) от атак, у нас обычно именно это называют "безопасностью"
- Пригодной к использованию (Usable)
- Подходящей (Suitable), пригодной для этих условий, функций и ограничений
- Эффективной (Efficient), тут деньги против ресурсов
- Работоспособной (Operable), то есть её можно запустить и поддерживать в работоспособном состоянии
- Гибкой (Flexible), легко можно менять. Coupling and Cohession - сюда.
Можно посмотреть примеры формулировок нефункциональных требований (тоже на английском): https://quality.arc42.org/requirements/
Требования описаны в трехчастной схеме: контекст-источник-метрика/критерий приемки.
Авторы говорят, что подход ISO 25010 не слишком прагматичный, поэтому они разработали свой . Возьмите, говорят, 7 категорий стейкхолдеров (пользователи, менеджмент, эксперты в предметной области, владелец продукта, разработчики, тестировщики, админы), и спросите у них, что им важно из общих или конкретных качеств системы. Ну да, из этих 162.
Получится очень прагматично.
Иногда выводил из на один слайд, получается впечатляюще.
Но теперь я нашел ещё более ужасающую картинку.
Это граф, в котором перечислено 162(!) атрибута качества и 104 примера требований, связанных с этим ограничениями. У каждого атрибута есть описание, то есть это не просто картинка, а целая энциклопедия (на английском).
Кажется, это исчерпывающий каталог атрибутов качества, куда уж больше.
Основа тут - восемь главных областей. Система должна быть:
- Надежной (Reliable)
- Безопасной (Safe), иногда переводят "свободной от неприемлемых рисков" - никого не убьет и не обанкротит, ничего не разрушит
- Защищенной (Secure) от атак, у нас обычно именно это называют "безопасностью"
- Пригодной к использованию (Usable)
- Подходящей (Suitable), пригодной для этих условий, функций и ограничений
- Эффективной (Efficient), тут деньги против ресурсов
- Работоспособной (Operable), то есть её можно запустить и поддерживать в работоспособном состоянии
- Гибкой (Flexible), легко можно менять. Coupling and Cohession - сюда.
Можно посмотреть примеры формулировок нефункциональных требований (тоже на английском): https://quality.arc42.org/requirements/
Требования описаны в трехчастной схеме: контекст-источник-метрика/критерий приемки.
Авторы говорят, что подход ISO 25010 не слишком прагматичный, поэтому они разработали свой . Возьмите, говорят, 7 категорий стейкхолдеров (пользователи, менеджмент, эксперты в предметной области, владелец продукта, разработчики, тестировщики, админы), и спросите у них, что им важно из общих или конкретных качеств системы. Ну да, из этих 162.
Получится очень прагматично.
👍8🤔3❤1
Forwarded from SWE notes
Putting the “You” in CPU
Отличный материал для погружения в работу ПК на примере Linux.
Простым языком описано что такое прерывание, мультизадачность и прочие системные вещи
#sysprog #linux #os
Отличный материал для погружения в работу ПК на примере Linux.
Простым языком описано что такое прерывание, мультизадачность и прочие системные вещи
#sysprog #linux #os
Putting the "You" in CPU
Curious exactly what happens when you run a program on your computer? Learn how multiprocessing works, what system calls really are, how computers manage memory with hardware interrupts, and how Linux loads executables.
👍5🔥2
Catalog of legacy modernization patterns by Nick Tune:
https://legacy-modernization.io/patterns/
https://legacy-modernization.io/patterns/
Legacy-Modernization.io
Patterns
Common patterns for modernizing legacy systems.
🔥10❤1
Forwarded from Russian Association of Software Architects (Ivan)
"On Orchestrators: You Are All Right, But You Are All Wrong Too"
by Anuun Chinbat, Junior Software Engineer
Мне показался интересным это раздел статьи с ссылками:
The Fundamentals
- A Brief History of Workflow Orchestration by Prefect.
- What is Data Orchestration and why is it misunderstood? by Hugo Lu.
- The evolution of data orchestration: Part 1 - the past and present by Jonathan Neo.
- The evolution of data orchestration: Part 2 - the future by Jonathan Neo.
- Bash-Script vs. Stored Procedure vs. Traditional - ETL Tools vs. Python-Script by Simon Späti.
by Anuun Chinbat, Junior Software Engineer
Мне показался интересным это раздел статьи с ссылками:
The Fundamentals
- A Brief History of Workflow Orchestration by Prefect.
- What is Data Orchestration and why is it misunderstood? by Hugo Lu.
- The evolution of data orchestration: Part 1 - the past and present by Jonathan Neo.
- The evolution of data orchestration: Part 2 - the future by Jonathan Neo.
- Bash-Script vs. Stored Procedure vs. Traditional - ETL Tools vs. Python-Script by Simon Späti.
Dlthub
On Orchestrators: You Are All Right, But You Are All Wrong Too
👍2
Forwarded from Russian Association of Software Architects (Сергей Баранов)
www.latent.space
The 2025 AI Engineering Reading List
We picked 50 paper/models/blogs across 10 fields in AI Eng: LLMs, Benchmarks, Prompting, RAG, Agents, CodeGen, Vision, Voice, Diffusion, Finetuning. If you're starting from scratch, start here.
👍4
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
С какими трудностями я обычно сталкивался в своей практике при реализации Specification Pattern? 1. Расслоение, если мы хотим применять его как для фильтрации объектов в оперативной памяти, так и в БД. Обычно эта проблема решается через Expression Tree, но…
Очень похоже на готовый Specification Pattern из коробки, причем, судя по исходникам, работает и с БД, и с объектами в оперативной памяти.
https://github.com/EvgSkv/logica
https://github.com/EvgSkv/logica
GitHub
GitHub - EvgSkv/logica: Logica is a logic programming language that compiles to SQL. It runs on DuckDB, Google BigQuery, PostgreSQL…
Logica is a logic programming language that compiles to SQL. It runs on DuckDB, Google BigQuery, PostgreSQL and SQLite. - EvgSkv/logica
👍3🔥2🙏1
Forwarded from Сергей Баранов
„Если ты хочешь построить корабль, не надо созывать людей, планировать, делить работу, доставать инструменты. Надо заразить людей стремлением к бесконечному морю. Тогда они сами построят корабль…“ — Антуан де Сент-Экзюпери
🔥14👍6👎3
Очень часто слышу "бизнес-логика" от слова "бизнес" - зарабатывать деньги.
Бизнес переводится с английского "дело".
"It's not your business!" - "Не твое дело!"
Бизнес логика - это то, что будет "делать" система или сервис. Это причина его возникновения.
В большинстве случаев "бизнес-логика" тождественна "доменной модели", когда система призвана автоматизировать какой-то процесс предметной области.
[UPDATE]:
-- Ward Cunningham
http://wiki.c2.com/?CategoryBusiness
Бизнес переводится с английского "дело".
"It's not your business!" - "Не твое дело!"
Бизнес логика - это то, что будет "делать" система или сервис. Это причина его возникновения.
В большинстве случаев "бизнес-логика" тождественна "доменной модели", когда система призвана автоматизировать какой-то процесс предметной области.
[UPDATE]:
Business - Software intersects with the Real World. Imagine that.
-- Ward Cunningham
http://wiki.c2.com/?CategoryBusiness
👍19🔥3❤1
Stay ahead, lead the future of AI in project management
Artificial intelligence (AI) is here to stay. Join us in leading the AI transformation where the future of project management blends AI and human ingenuity, fueled and guided by our global community.
https://www.pmi.org/learning/ai-in-project-management
Artificial intelligence (AI) is here to stay. Join us in leading the AI transformation where the future of project management blends AI and human ingenuity, fueled and guided by our global community.
https://www.pmi.org/learning/ai-in-project-management
www.pmi.org
Artificial Intelligence in Project Management | PMI
AI is impacting the future of project management and changing how professionals approach projects. Learn how to leverage AI in project management today.
Leading AI Transformation: Organizational Strategies for Project Professionals
Project Management Institute
Drive innovation with frameworks to harness, scale, and institutionalize AI for company-wide success.
https://www.pmi.org/standards/leading-ai-transformation-organizational-strategies-for-project-professionals
Project Management Institute
Drive innovation with frameworks to harness, scale, and institutionalize AI for company-wide success.
https://www.pmi.org/standards/leading-ai-transformation-organizational-strategies-for-project-professionals
www.pmi.org
Leading AI Transformation: Organizational Strategies for Project Professionals
Drive innovation with frameworks to harness, scale, and institutionalize AI for company-wide success.
AI Essentials for Project Professionals
A companion guide to incorporating AI in day-to-day project management.
https://www.pmi.org/standards/ai-essentials-for-project-professionals
A companion guide to incorporating AI in day-to-day project management.
https://www.pmi.org/standards/ai-essentials-for-project-professionals
www.pmi.org
AI Essentials for Project Professionals
🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
Из г...глины и палок? Чтобы работало? Легко! В руках мастера, как говорится...
Даже не знаю, что меня смущает больше — деревянный мотоцикл или глиняный шлем.
Даже не знаю, что меня смущает больше — деревянный мотоцикл или глиняный шлем.
🔥5😁5👍3🤩1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
В предыдущем посте говорилось, что pessimistic scenario не совсем корректен в Taskjuggler. Картинка демонстрирует, как должны быть сложены две оценки. Мы видим, что оценки пересекаются. Вот почему мы должны сложить отдельно вероятностную оценку и среднеквадратичное…
Добавил в TaskJuggler поддержку подсчета Standard Deviation:
https://github.com/emacsway/TaskJuggler/tree/standard_deviation
Ранее я объяснял, почему использование пессимистического сценария для подсчета пессимистического срока некорректно.
Как это работает у меня сейчас. Мой коллега разработал для Jira плагин, который позволяет вводить трехточечную оценку по методу PERT. Это очень важный плагин, который решает целый ряд проблем, начиная от психологических (разработчики склонны оптимизировать оценки, а бизнес склонен воспринимать планирование как обязательство и понукать сроками) и заканчивая математическими (вероятностную распределенность невозможно выразить одним значением).
Из трех значений плагин выводит вероятностную оценку и среднеквадратичное отклонение. Если хотите посчитать вручную, то это можно сделать с помощью PERT-калькулятора. Далее эти оценки по специальным правилам суммируются, но в контекста TaskJuggler функции и возможности плагина нам уже не интересны.
Интеграционный скрипт при экспорте задач из Jira в TaskJuggler извлекает эти оценки и высчитывает вероятностную оценку (effort) и среднеквадратичное отклонение (stdev).
Для контейнерного типа задач TaskJuggler суммирует stdev как корень квадратный суммы квадратов. Значение получается в человеко-днях уже с учетом фокус-фактора.
Для нахождения пессимистического срока эпика используется правило 3×sigma. Т.е. к сроку, полученному на основании вероятностных оценок, добавляется еще три среднеквадратичных отклонения, преобразованных в календарные дни (т.е. с учетом выходных дней, например, при σ=5 это будет три календарные недели).
Список литературы по планированию см. здесь.
#Estimation #Scheduling #TaskJuggler #PERT
https://github.com/emacsway/TaskJuggler/tree/standard_deviation
Ранее я объяснял, почему использование пессимистического сценария для подсчета пессимистического срока некорректно.
Как это работает у меня сейчас. Мой коллега разработал для Jira плагин, который позволяет вводить трехточечную оценку по методу PERT. Это очень важный плагин, который решает целый ряд проблем, начиная от психологических (разработчики склонны оптимизировать оценки, а бизнес склонен воспринимать планирование как обязательство и понукать сроками) и заканчивая математическими (вероятностную распределенность невозможно выразить одним значением).
Из трех значений плагин выводит вероятностную оценку и среднеквадратичное отклонение. Если хотите посчитать вручную, то это можно сделать с помощью PERT-калькулятора. Далее эти оценки по специальным правилам суммируются, но в контекста TaskJuggler функции и возможности плагина нам уже не интересны.
Интеграционный скрипт при экспорте задач из Jira в TaskJuggler извлекает эти оценки и высчитывает вероятностную оценку (effort) и среднеквадратичное отклонение (stdev).
Для контейнерного типа задач TaskJuggler суммирует stdev как корень квадратный суммы квадратов. Значение получается в человеко-днях уже с учетом фокус-фактора.
Для нахождения пессимистического срока эпика используется правило 3×sigma. Т.е. к сроку, полученному на основании вероятностных оценок, добавляется еще три среднеквадратичных отклонения, преобразованных в календарные дни (т.е. с учетом выходных дней, например, при σ=5 это будет три календарные недели).
Список литературы по планированию см. здесь.
#Estimation #Scheduling #TaskJuggler #PERT
GitHub
GitHub - emacsway/TaskJuggler at standard_deviation
TaskJuggler - Project Management beyond Gantt chart drawing - GitHub - emacsway/TaskJuggler at standard_deviation
🔥11❤1👍1🙏1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Добавил в TaskJuggler поддержку подсчета Standard Deviation: https://github.com/emacsway/TaskJuggler/tree/standard_deviation Ранее я объяснял, почему использование пессимистического сценария для подсчета пессимистического срока некорректно. Как это работает…
Зачем нужно стандартное отклонение?
Существует три качества оценки:
1. Honest (честность)
2. Accurate (достоверность, например, утверждение о том, что задача будет выполнена за период времени от текущего момента до конца существования Вселенной - это Accurate, но не Precise)
3. Precise (точность, т.е. сужение диапазона вероятности оценки, например, утверждение о том, что задача будет выполнена 11 октября 2025 года в 15:45:10.0639 - это Precise, но не Accurate)
Было хорошее видео на эту тему "YOW! 2016 Robert C. Martin - Effective Estimation (or: How not to Lie)", но сейчас оно, к сожалению, недоступно. Может можно найти его копии где-нибудь.
Проблема в том, что достигнуть одновременно всех этих трех показателей в оценке, выраженной в виде единственного значения в человеко-днях, невозможно. Вернее, единственный способ это сделать - это осуществить реализацию всех сторей.
Оценка - это диапазон. И диапазон с вероятностной распределенностью.
На этом построен принцип оценивания PERT, который снимает психологическое напряжение и позволяет выразить степень неопределенности оценки в виде среднеквадратичного отклонения. Коротко этот подход описан на 3-х страницах книги "The Clean Coder" by Robert C. Martin, "Chapter 10 Estimation :: PERT". На русском она называется "Иделальный программист".
Для каждой стори снимаются 3 оценки - пессимистическая, номинальная и оптимистическая.
При коллективном оценивании для пессимистической берется самая пессимистическая из всех, для номинальной - средняя, для оптимистической - самая оптимистическая.
Вычисление можно легко осуществить в excel-файлике. Вероятностая оценка находится по формуле μ = (O + 4 N + P) / 6. А среднеквадратичное отклонение распределения времени выполнения стори находится по формуле σ = (P − O) / 6. Этот параметр выражает точность оценки.
Далее суммируются вероятностные оценки для всех сторей релизного цикла простым математическим сложением, это несложно сделать в excel. А вот среднеквадратичное отклонение распределения времени выполнения всех сторей высчитывается немного сложней, и равно квадратному корню суммы квадратов среднеквадратичных отклонений сторей, т.е. σ sequence = (∑ (σ story ^ 2)) ^1/2. Это тоже несложно автоматизировать в excel.
Ну а далее, как я уже говорил, для нахождения пессимистического срока релиза используется правило 3×sigma. Т.е. к сроку, полученному на основании вероятностных оценок, добавляется еще три среднеквадратичных отклонения, преобразованных в календарные дни (т.е. с учетом выходных дней, например, при σ=5 это будет три календарные недели).
На контрольных точках релизного цикла делаются сверки реального отклонения с запланированным резервом в виде трёх сигм, вычисленного для уже реализованных задач контрольной точки. В случае, если обнаруживается, что реальное отклонение превышает запланированный резерв, бизнес своевременно информируется об угрозе нарушения срока релиза.
Важно понимать, что планирование - это не предсказание (Kent Beck). А прогноз - это не обязательство (Robert Martin).
Планирование в адаптивных моделях разработки делается не для того, чтобы понукать разработчиков сроками, а для раннего обнаружения отклонения от плана с целью предоставления бизнесу наибольшего простора для бизнес-манёвра.
Проблемой для бизнеса является не сам факт отклонения от плана, а когда он слишком поздно узнает об отклонении и уже не может ничего предпринять.
Существует три качества оценки:
1. Honest (честность)
2. Accurate (достоверность, например, утверждение о том, что задача будет выполнена за период времени от текущего момента до конца существования Вселенной - это Accurate, но не Precise)
3. Precise (точность, т.е. сужение диапазона вероятности оценки, например, утверждение о том, что задача будет выполнена 11 октября 2025 года в 15:45:10.0639 - это Precise, но не Accurate)
Было хорошее видео на эту тему "YOW! 2016 Robert C. Martin - Effective Estimation (or: How not to Lie)", но сейчас оно, к сожалению, недоступно. Может можно найти его копии где-нибудь.
Проблема в том, что достигнуть одновременно всех этих трех показателей в оценке, выраженной в виде единственного значения в человеко-днях, невозможно. Вернее, единственный способ это сделать - это осуществить реализацию всех сторей.
Оценка - это диапазон. И диапазон с вероятностной распределенностью.
На этом построен принцип оценивания PERT, который снимает психологическое напряжение и позволяет выразить степень неопределенности оценки в виде среднеквадратичного отклонения. Коротко этот подход описан на 3-х страницах книги "The Clean Coder" by Robert C. Martin, "Chapter 10 Estimation :: PERT". На русском она называется "Иделальный программист".
Для каждой стори снимаются 3 оценки - пессимистическая, номинальная и оптимистическая.
При коллективном оценивании для пессимистической берется самая пессимистическая из всех, для номинальной - средняя, для оптимистической - самая оптимистическая.
Вычисление можно легко осуществить в excel-файлике. Вероятностая оценка находится по формуле μ = (O + 4 N + P) / 6. А среднеквадратичное отклонение распределения времени выполнения стори находится по формуле σ = (P − O) / 6. Этот параметр выражает точность оценки.
Далее суммируются вероятностные оценки для всех сторей релизного цикла простым математическим сложением, это несложно сделать в excel. А вот среднеквадратичное отклонение распределения времени выполнения всех сторей высчитывается немного сложней, и равно квадратному корню суммы квадратов среднеквадратичных отклонений сторей, т.е. σ sequence = (∑ (σ story ^ 2)) ^1/2. Это тоже несложно автоматизировать в excel.
Ну а далее, как я уже говорил, для нахождения пессимистического срока релиза используется правило 3×sigma. Т.е. к сроку, полученному на основании вероятностных оценок, добавляется еще три среднеквадратичных отклонения, преобразованных в календарные дни (т.е. с учетом выходных дней, например, при σ=5 это будет три календарные недели).
На контрольных точках релизного цикла делаются сверки реального отклонения с запланированным резервом в виде трёх сигм, вычисленного для уже реализованных задач контрольной точки. В случае, если обнаруживается, что реальное отклонение превышает запланированный резерв, бизнес своевременно информируется об угрозе нарушения срока релиза.
Важно понимать, что планирование - это не предсказание (Kent Beck). А прогноз - это не обязательство (Robert Martin).
Планирование в адаптивных моделях разработки делается не для того, чтобы понукать разработчиков сроками, а для раннего обнаружения отклонения от плана с целью предоставления бизнесу наибольшего простора для бизнес-манёвра.
Проблемой для бизнеса является не сам факт отклонения от плана, а когда он слишком поздно узнает об отклонении и уже не может ничего предпринять.
Telegram
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Добавил в TaskJuggler поддержку подсчета Standard Deviation:
https://github.com/emacsway/TaskJuggler/tree/standard_deviation
Ранее я объяснял, почему использование пессимистического сценария для подсчета пессимистического срока некорректно.
Как это работает…
https://github.com/emacsway/TaskJuggler/tree/standard_deviation
Ранее я объяснял, почему использование пессимистического сценария для подсчета пессимистического срока некорректно.
Как это работает…
🔥8👍7🙏3
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Физические Agile-доски до сих пор активно используются в крупных IT-компаниях, даже в таких, как Thoughtworks. Это никакой не исторический рудимент. Они используются даже для распределенных команд - в удаленном офисе на самом видном месте устанавливается большой…
Прошло уже 3 месяца, как в моей практике появился физический бумажный ежедневник.
Теперь могу уверенно ответить на вопрос о том, есть ли от него реальная польза, или это просто эффект новизы.
Главное отличие, которое я заметил - это необычайно глубокое владение обстановкой и высокий уровень самоорганизованности.
Я обсуждал этот вопрос с моим товарищем, к.т.н., который работает над докторской, и тоже пользуется бумажным ежедневником. Я не спец в физиологии и не могу в точности передать содержание разговора, но он мне объяснил о наличии некой связи между нейронами, отвечающими за мелкую моторику, и нейронами, отвечающими за память. Эта тема даже неплохо освещена в интернете, например:
https://hi-tech.mail.ru/news/119776-pismo-ot-ruki-luchshe-prokachivaet-nejronnye-svyazi-chem-pechat-novye-dannye/
Тоже замечал, что запись в бумажный ежедневник лучше фиксируется в памяти, отсюда и превосходное владение производственной обстановкой.
Наверное, поэтому С.И. Поварнин в своей книге "Как читать книги" рекомендует конспектировать прочитанное.
Иногда намеренно записываю информацию в бумажный ежедневник, а затем сканирую текст приложением "Почерк в текст конвертор", чтоб перенести в цифровой блокнот.
Я пользуюсь форматами A6 и Personal. A6 удобней, но мне подвернулся по хорошей цене оригинальный новый Montblanc формата Personal.
Самым удобным форматом наполнения для меня оказался https://myfineplan.ru/product/blok-nedelya-v2-2 , т.к. он содержит страницу для заметок на каждую неделю. Но, если честно, места на странице недельного расписания (т.е. на левой) частенько не хватает.
Какие и где блокноты можно купить?
1. https://myfineplan.ru/
У этой мастерской есть телеграм-канал:
https://news.1rj.ru/str/myfineplan
2. На Авито часто бывают в продаже шикарные ежедневники из натуральной кожи Petek в непритронутом виде (просто лежал у кого-то дома в заводской упаковке). По непонятной для меня причине они лучше находятся по фразе "записная книжка Petek". Иногда попадаются Dupont и Montblanc.
3. На Aliexpress можно купить блокноты Moterm и Filofax. Мне очень нравится Filofax Holborn формата Personal, который есть в моей коллекции.
Цифровой блокнот из моей практики не исчез, продолжаю пользоваться
https://github.com/orgzly-revived/orgzly-android-revived
, который подкупил меня внутренним качеством своей кодовой базы по сравнению с другими Open Source решениями.
P.S.: Знаете чем обусловлен успех Юрия Никулина? Что для него было самым ценным, и прошло с ним через всю войну? Блокнот (в виде тетради), в который он записывал анекдоты.
Теперь могу уверенно ответить на вопрос о том, есть ли от него реальная польза, или это просто эффект новизы.
Главное отличие, которое я заметил - это необычайно глубокое владение обстановкой и высокий уровень самоорганизованности.
Я обсуждал этот вопрос с моим товарищем, к.т.н., который работает над докторской, и тоже пользуется бумажным ежедневником. Я не спец в физиологии и не могу в точности передать содержание разговора, но он мне объяснил о наличии некой связи между нейронами, отвечающими за мелкую моторику, и нейронами, отвечающими за память. Эта тема даже неплохо освещена в интернете, например:
https://hi-tech.mail.ru/news/119776-pismo-ot-ruki-luchshe-prokachivaet-nejronnye-svyazi-chem-pechat-novye-dannye/
Тоже замечал, что запись в бумажный ежедневник лучше фиксируется в памяти, отсюда и превосходное владение производственной обстановкой.
Наверное, поэтому С.И. Поварнин в своей книге "Как читать книги" рекомендует конспектировать прочитанное.
Иногда намеренно записываю информацию в бумажный ежедневник, а затем сканирую текст приложением "Почерк в текст конвертор", чтоб перенести в цифровой блокнот.
Я пользуюсь форматами A6 и Personal. A6 удобней, но мне подвернулся по хорошей цене оригинальный новый Montblanc формата Personal.
Самым удобным форматом наполнения для меня оказался https://myfineplan.ru/product/blok-nedelya-v2-2 , т.к. он содержит страницу для заметок на каждую неделю. Но, если честно, места на странице недельного расписания (т.е. на левой) частенько не хватает.
Какие и где блокноты можно купить?
1. https://myfineplan.ru/
У этой мастерской есть телеграм-канал:
https://news.1rj.ru/str/myfineplan
2. На Авито часто бывают в продаже шикарные ежедневники из натуральной кожи Petek в непритронутом виде (просто лежал у кого-то дома в заводской упаковке). По непонятной для меня причине они лучше находятся по фразе "записная книжка Petek". Иногда попадаются Dupont и Montblanc.
3. На Aliexpress можно купить блокноты Moterm и Filofax. Мне очень нравится Filofax Holborn формата Personal, который есть в моей коллекции.
Цифровой блокнот из моей практики не исчез, продолжаю пользоваться
https://github.com/orgzly-revived/orgzly-android-revived
, который подкупил меня внутренним качеством своей кодовой базы по сравнению с другими Open Source решениями.
P.S.: Знаете чем обусловлен успех Юрия Никулина? Что для него было самым ценным, и прошло с ним через всю войну? Блокнот (в виде тетради), в который он записывал анекдоты.
Hi-Tech Mail
Письмо от руки лучше прокачивает нейронные связи: лайфхак
Ученые обнаружили, что письмо от руки активирует более широкие и взаимосвязанные сети мозга, особенно в областях, связанных с памятью и сенсорной обработкой, чем набор текста на клавиатуре. Рассказываем об исследовании подробнее.
❤9👍6🔥1