Если вам вдруг нечем заняться в зимний воскресный день, предлагаю задачку.
У программистов есть классическая, даже легендарная задача на собеседовании: FizzBuzz.
Нужно написать программу, которая для каждого числа от 1 до 100 выдает либо Fizz (если число делится без остатка на 3), либо Buzz (если число делится без остатка на 5), либо FizzBuzz, если число делится без остатка и на 3, и на 5. Если число не делится ни на 3, ни на 5 — нужно выдать само это число.
Задачу так часто давали разработчикам на интервью, что это стало уже анекдотом.
А решается она настолько просто, что появились разновидности с усложнением: FizzBuzz только с двумя if; FizzBuzz с двумя if без использования переменных; вообще без if и без переменных; без использования операции взятия остатка и т.д.
Есть решения невероятной сложности — например,
FizzBuzz на косинусах и дискретных преобразованиях Фурье: https://habr.com/ru/articles/969856/ (осторожно, в посте для вывода используется формула Эйлера комплексными числами, я вас предупредил), или
FizzBuzz на TensorFlow, на основе многослойного перцептрона со скрытым слоем: https://habr.com/ru/articles/301536/.
Впрочем, ближе к нам корпоративная реализация FizzBuzz: https://habr.com/ru/companies/contentai/articles/173885/ (язык — Java; 102 файла, разложенных по 44 папкам; используются такие ООП-паттерны, как Стратегия, Абстрактная фабрика, Декоратор, Адаптер; есть тесты). Впрочем, как пишут многие критики, до настоящего ПО корпоративного уровня этому решению далеко.
Вот я и предлагаю вам потренироваться — написать максимально полный набор требований к FizzBuzz. Что там должно быть? Что упускают все авторы? Давайте покажем этим программистам, что на самом деле они постоянно не учитывают в своих решениях!
У программистов есть классическая, даже легендарная задача на собеседовании: FizzBuzz.
Нужно написать программу, которая для каждого числа от 1 до 100 выдает либо Fizz (если число делится без остатка на 3), либо Buzz (если число делится без остатка на 5), либо FizzBuzz, если число делится без остатка и на 3, и на 5. Если число не делится ни на 3, ни на 5 — нужно выдать само это число.
Задачу так часто давали разработчикам на интервью, что это стало уже анекдотом.
А решается она настолько просто, что появились разновидности с усложнением: FizzBuzz только с двумя if; FizzBuzz с двумя if без использования переменных; вообще без if и без переменных; без использования операции взятия остатка и т.д.
Есть решения невероятной сложности — например,
FizzBuzz на косинусах и дискретных преобразованиях Фурье: https://habr.com/ru/articles/969856/ (осторожно, в посте для вывода используется формула Эйлера комплексными числами, я вас предупредил), или
FizzBuzz на TensorFlow, на основе многослойного перцептрона со скрытым слоем: https://habr.com/ru/articles/301536/.
Впрочем, ближе к нам корпоративная реализация FizzBuzz: https://habr.com/ru/companies/contentai/articles/173885/ (язык — Java; 102 файла, разложенных по 44 папкам; используются такие ООП-паттерны, как Стратегия, Абстрактная фабрика, Декоратор, Адаптер; есть тесты). Впрочем, как пишут многие критики, до настоящего ПО корпоративного уровня этому решению далеко.
Вот я и предлагаю вам потренироваться — написать максимально полный набор требований к FizzBuzz. Что там должно быть? Что упускают все авторы? Давайте покажем этим программистам, что на самом деле они постоянно не учитывают в своих решениях!
😁12❤6🔥5🥰2🤯2
Обсуждение FizzBuzz напомнило про старую задачку на моделирование классов и взаимодействия: как замоделировать ситуацию "человек пьет кофе из кружки".
Очевидно, у нас будут классы "человек" и "кружка", и, например, уровень кофе в кружке. А вот про взаимодействие вопрос: где живет метод "пить"? Класс "человек" отправляет сообщение "пить(объем кофе)" классу "кружка" ( person->cup.drink(30) )? Или человек пьет, а кружка тогда что делает? ( person.drinkFrom(cup,30) )
Я не помню, у кого я видел обсуждение этой задачи. Но пока искал, нашел прекрасную статью Грегора Хопа (соавтора "Паттернов интеграции корпоративных приложений") с иллюстрацией синхронной и асинхронной интеграции на примере Starbucks.
Если вы помните, заказ в Starbucks принимают синхронно: вы не можете в процессе заказа и оплаты отойти на минуточку, а потом вернуться. Заказ и оплата выполняются в одном синхронном взаимодействии, даже если растягивается по времени.
А вот приготовление выполняется асинхронно:
— разные напитки требуют разного времени приготовления
— разное оборудование может быть использовано параллельно
— приготовление может вставать в очередь, когда оборудование занято
— заказы могут быть готовы не в той последовательности, в которой были сделаны
Почему так сделано? Для увеличения пропускной способности. Если у вас один человек принимает оплату, а потом сам готовит кофе — вы получаете кофе быстрее (ваш заказ взят в работу сразу же), но за вами копится очередь, и часть людей может уйти, не дождавшись. Асинхронность позволяет легко организовать горизонтальное масштабирование — можно увеличить число барист.
Тем не менее, транзакция закончена только когда клиент получил напиток. В нашей гибридной архитектуре — с синхронным и асинхронным взаимодействием — транзакция становится распределенной. Тут можно увидеть несколько паттернов:
— Идентификатор корреляции (Correlation ID), чтобы сопоставить приготовленный напиток и заказ. В Starbucks в качестве этого идентификатора используют имя клиента.
— Обработка исключений. Когда описывают "саги", всегда пишут про компенсирующие действия. Но Хоп пишет, что есть три варианта:
1. Списание. Если транзакция завершилась неудачей, мы просто ничего не делаем. А что уже сделали — выбрасываем (списываем). Возможно, механизм исправления ошибки будет стоить дороже. Иногда у нас просто нет другой возможности, а иногда это бизнес-решение: если клиент не забрал напиток, его через какое-то время нужно вылить.
2. Повторная попытка. Если в ходе транзакции возник технический сбой, а не нарушение бизнес-правила, можно попробовать повторить действие. Чтобы не заморачиваться, можно повторить все действия (но для этого у нас должны быть идемпотентные получатели, чтобы можно было безопасно повторить все запросы, начиная с первого). Если кофемашина сломалась, нужно повторить все действия на другой.
3. Компенсирующие действия — выполнение обратных операций. Если мы совсем не смогли приготовить кофе, придется вернуть деньги.
— Альтернатива — двухфазный коммит, когда кассир выступает координатором, и принимает оплату только после приготовления напитка. Это сильно задерживает выполнение транзакции, но зато система никогда не находится в несогласованном состоянии. В реальном мире это, например, счета эскроу.
Что ещё можно вспомнить? Если рассмотреть другие закусочные, то можно увидеть паттерн Claim Check — когда клиент получает не финальный (тяжелый) результат, а чек, с которым он приходит за заказом. Тогда идентификатор корреляции — номер заказа, который есть на чеке.
И, раз мы используем гибридный подход, можем увидеть и паттерны синхронных взаимодействий:
— если у кассира сломалась касса или клиент замешкался с оплатой, можно открыть вторую кассу и перенаправить ожидающих клиентов туда — это паттерн Circuit Breaker, размыкатель. Как вариант — перестает принимать заказы на определенный вид напитка, например, если сломался капучинатор.
Все паттерны взаимодействия пришли из реального мира, в конечном счете.
Очевидно, у нас будут классы "человек" и "кружка", и, например, уровень кофе в кружке. А вот про взаимодействие вопрос: где живет метод "пить"? Класс "человек" отправляет сообщение "пить(объем кофе)" классу "кружка" ( person->cup.drink(30) )? Или человек пьет, а кружка тогда что делает? ( person.drinkFrom(cup,30) )
Я не помню, у кого я видел обсуждение этой задачи. Но пока искал, нашел прекрасную статью Грегора Хопа (соавтора "Паттернов интеграции корпоративных приложений") с иллюстрацией синхронной и асинхронной интеграции на примере Starbucks.
Если вы помните, заказ в Starbucks принимают синхронно: вы не можете в процессе заказа и оплаты отойти на минуточку, а потом вернуться. Заказ и оплата выполняются в одном синхронном взаимодействии, даже если растягивается по времени.
А вот приготовление выполняется асинхронно:
— разные напитки требуют разного времени приготовления
— разное оборудование может быть использовано параллельно
— приготовление может вставать в очередь, когда оборудование занято
— заказы могут быть готовы не в той последовательности, в которой были сделаны
Почему так сделано? Для увеличения пропускной способности. Если у вас один человек принимает оплату, а потом сам готовит кофе — вы получаете кофе быстрее (ваш заказ взят в работу сразу же), но за вами копится очередь, и часть людей может уйти, не дождавшись. Асинхронность позволяет легко организовать горизонтальное масштабирование — можно увеличить число барист.
Тем не менее, транзакция закончена только когда клиент получил напиток. В нашей гибридной архитектуре — с синхронным и асинхронным взаимодействием — транзакция становится распределенной. Тут можно увидеть несколько паттернов:
— Идентификатор корреляции (Correlation ID), чтобы сопоставить приготовленный напиток и заказ. В Starbucks в качестве этого идентификатора используют имя клиента.
— Обработка исключений. Когда описывают "саги", всегда пишут про компенсирующие действия. Но Хоп пишет, что есть три варианта:
1. Списание. Если транзакция завершилась неудачей, мы просто ничего не делаем. А что уже сделали — выбрасываем (списываем). Возможно, механизм исправления ошибки будет стоить дороже. Иногда у нас просто нет другой возможности, а иногда это бизнес-решение: если клиент не забрал напиток, его через какое-то время нужно вылить.
2. Повторная попытка. Если в ходе транзакции возник технический сбой, а не нарушение бизнес-правила, можно попробовать повторить действие. Чтобы не заморачиваться, можно повторить все действия (но для этого у нас должны быть идемпотентные получатели, чтобы можно было безопасно повторить все запросы, начиная с первого). Если кофемашина сломалась, нужно повторить все действия на другой.
3. Компенсирующие действия — выполнение обратных операций. Если мы совсем не смогли приготовить кофе, придется вернуть деньги.
— Альтернатива — двухфазный коммит, когда кассир выступает координатором, и принимает оплату только после приготовления напитка. Это сильно задерживает выполнение транзакции, но зато система никогда не находится в несогласованном состоянии. В реальном мире это, например, счета эскроу.
Что ещё можно вспомнить? Если рассмотреть другие закусочные, то можно увидеть паттерн Claim Check — когда клиент получает не финальный (тяжелый) результат, а чек, с которым он приходит за заказом. Тогда идентификатор корреляции — номер заказа, который есть на чеке.
И, раз мы используем гибридный подход, можем увидеть и паттерны синхронных взаимодействий:
— если у кассира сломалась касса или клиент замешкался с оплатой, можно открыть вторую кассу и перенаправить ожидающих клиентов туда — это паттерн Circuit Breaker, размыкатель. Как вариант — перестает принимать заказы на определенный вид напитка, например, если сломался капучинатор.
Все паттерны взаимодействия пришли из реального мира, в конечном счете.
❤25🔥14👍3
Удивительно, но я никогда не видел хороших чеклистов для микросервисов, особенно для проверки — правильно ли они выделены, всё ли продумано.
Обычно попадаются чеклисты для проверки технических вещей, чуть ли не на уровне DevOps. Примеры: раз, два.
Культура чеклистов вообще не очень развита, многие не понимают, что это. Дают просто существительные. [ ] Sync vs. Async/Event-based processing. И что я тут должен поставить?
Во многих чеклистах забывают или игнорируют вопрос — зачем сервисы вообще нужны? Это понятно, ведь составляют их архитекторы или разработчики.
Поэтому пришлось сделать свой чеклист, подходящий для системных аналитиков. Держите:
1. Идентичность и ответственность
1.1. Можем описать ответственность сервиса одной фразой без «и», «а также», «кроме того», «плюс».
1.2. Понятно, какой бизнес-драйвер обосновывает существование сервиса (скорость изменения этого субдомена, масштабирование/нагрузки, сокращение TTM, регуляторные требования/безопасность, снижение/изоляция ошибок и т.п.).
1.3. Можно назвать 1 ключевую бизнес-способность, за которую отвечает сервис
2. Границы и связи с другими сервисами
2.1. Для сервиса понятен список use-case’ов, в которых он:
— ведущий (владеет бизнес-логикой),
— участник (вызывается другим сервисом, реагирует на событие).
2.2. Сервису не нужен прямой доступ в базу других сервисов; только через API/события.
2.3. Есть разумный список зависимостей от других сервисов (входящих и исходящих), нет "всех со всеми".
2.4. Сервис не является "божественным объектом" — не пытается делать всё для всех.
3. Данные и инварианты
3.1. Определены основные агрегаты/сущности, которыми владеет сервис (список 3–7 штук).
3.2. Для ключевых данных описаны инварианты: что "никогда не должно нарушаться"
3.3. Для каждого инварианта определен механизм, за счет которого он соблюдается (бизнес-логика, ограничения БД, контракты взаимодействия)
3.4. Для сервиса определены объемы и профили хранения данных (типичный объем хранения; прирост; вывод устаревших данных/архивация; доля "горячих" и "холодных" данных)
3.5. Для 1–2 основных сущностей сервиса описаны: этапы жизненного цикла (статусы), допустимые переходы между ними, кто инициирует какой переход (use-case / входящее событие).
3.6. Для ключевых сущностей предусмотрены все операции CRUD (понятно, кто их делает, есть API) + архивирование/хранение истории
3.7. Приняты решения по модели чтения (CQRS, Event Sourcing)
4. Контракты, схемы и API
4.1. Составлен список внешних операций:
— команды (изменяют состояние),
— запросы (чтение),
— доменные события (что сервис публикует).
4.2. Методы разумно гранулированы: нет «мега-методов», которые делают всё сразу, и нет чрезмерно мелких операций, создающих "болтливые" (chatty) API.
4.3. Для ключевых операций определена модель ошибок и контракты ответов/обработки:
— ошибки бизнес-уровня (валидация полей, попытки нарушения инвариантов, недостаток данных из-за Eventual Consistency),
— какие — технические,
— как клиент понимает, что делать (повторять/не повторять/обращаться в поддержку).
4.4. Определена стратегия эволюции структуры API и схем данных: принудительное обновление клиентов / поддержка нескольких версий API / схем
4.5. Все события описаны как контракт: есть описание схемы; определены гарантии доставки / сохранения порядка
4.6. Определены идемпотентные операции и механизмы обеспечения идемпотентности
5. Надёжность, производительность, наблюдаемость
5.1. Для ключевых операций определены SLO:
— латентность
— доступность
— процент ошибок
5.2. Поведение при отказах: понятно, что делает сервис:
— при падении зависимого сервиса,
— при перегрузке (ограничение, деградация, очереди),
— есть ли таймауты, ретраи, circuit breaker, алгоритм перепосылок
5.3. Определена тактика горизонтального масштабирования и распределения нагрузки: round robin, деление по данным, по клиентам
5.4. Выявлены потенциальные узкие места (БД, внешняя интеграция, блокирующие операции, большие файлы, состояния гонки), приняты решения по их расшивке
5.5. Определены отслеживаемые бизнес-метрики, технические метрики и ключевые события для логирования
Обычно попадаются чеклисты для проверки технических вещей, чуть ли не на уровне DevOps. Примеры: раз, два.
Культура чеклистов вообще не очень развита, многие не понимают, что это. Дают просто существительные. [ ] Sync vs. Async/Event-based processing. И что я тут должен поставить?
Во многих чеклистах забывают или игнорируют вопрос — зачем сервисы вообще нужны? Это понятно, ведь составляют их архитекторы или разработчики.
Поэтому пришлось сделать свой чеклист, подходящий для системных аналитиков. Держите:
1. Идентичность и ответственность
1.1. Можем описать ответственность сервиса одной фразой без «и», «а также», «кроме того», «плюс».
1.2. Понятно, какой бизнес-драйвер обосновывает существование сервиса (скорость изменения этого субдомена, масштабирование/нагрузки, сокращение TTM, регуляторные требования/безопасность, снижение/изоляция ошибок и т.п.).
1.3. Можно назвать 1 ключевую бизнес-способность, за которую отвечает сервис
2. Границы и связи с другими сервисами
2.1. Для сервиса понятен список use-case’ов, в которых он:
— ведущий (владеет бизнес-логикой),
— участник (вызывается другим сервисом, реагирует на событие).
2.2. Сервису не нужен прямой доступ в базу других сервисов; только через API/события.
2.3. Есть разумный список зависимостей от других сервисов (входящих и исходящих), нет "всех со всеми".
2.4. Сервис не является "божественным объектом" — не пытается делать всё для всех.
3. Данные и инварианты
3.1. Определены основные агрегаты/сущности, которыми владеет сервис (список 3–7 штук).
3.2. Для ключевых данных описаны инварианты: что "никогда не должно нарушаться"
3.3. Для каждого инварианта определен механизм, за счет которого он соблюдается (бизнес-логика, ограничения БД, контракты взаимодействия)
3.4. Для сервиса определены объемы и профили хранения данных (типичный объем хранения; прирост; вывод устаревших данных/архивация; доля "горячих" и "холодных" данных)
3.5. Для 1–2 основных сущностей сервиса описаны: этапы жизненного цикла (статусы), допустимые переходы между ними, кто инициирует какой переход (use-case / входящее событие).
3.6. Для ключевых сущностей предусмотрены все операции CRUD (понятно, кто их делает, есть API) + архивирование/хранение истории
3.7. Приняты решения по модели чтения (CQRS, Event Sourcing)
4. Контракты, схемы и API
4.1. Составлен список внешних операций:
— команды (изменяют состояние),
— запросы (чтение),
— доменные события (что сервис публикует).
4.2. Методы разумно гранулированы: нет «мега-методов», которые делают всё сразу, и нет чрезмерно мелких операций, создающих "болтливые" (chatty) API.
4.3. Для ключевых операций определена модель ошибок и контракты ответов/обработки:
— ошибки бизнес-уровня (валидация полей, попытки нарушения инвариантов, недостаток данных из-за Eventual Consistency),
— какие — технические,
— как клиент понимает, что делать (повторять/не повторять/обращаться в поддержку).
4.4. Определена стратегия эволюции структуры API и схем данных: принудительное обновление клиентов / поддержка нескольких версий API / схем
4.5. Все события описаны как контракт: есть описание схемы; определены гарантии доставки / сохранения порядка
4.6. Определены идемпотентные операции и механизмы обеспечения идемпотентности
5. Надёжность, производительность, наблюдаемость
5.1. Для ключевых операций определены SLO:
— латентность
— доступность
— процент ошибок
5.2. Поведение при отказах: понятно, что делает сервис:
— при падении зависимого сервиса,
— при перегрузке (ограничение, деградация, очереди),
— есть ли таймауты, ретраи, circuit breaker, алгоритм перепосылок
5.3. Определена тактика горизонтального масштабирования и распределения нагрузки: round robin, деление по данным, по клиентам
5.4. Выявлены потенциальные узкие места (БД, внешняя интеграция, блокирующие операции, большие файлы, состояния гонки), приняты решения по их расшивке
5.5. Определены отслеживаемые бизнес-метрики, технические метрики и ключевые события для логирования
1❤22👍11🔥6👏1🤣1
Если вам удобнее использовать Canvas — для микросервисов есть и он, конечно. Точнее, даже не для самих микросервисов, а для ограниченных контекстов (спасибо Денису Мигулину за наводку).
Разделы:
Название
Смысл (Purpose) — бизнес-смысл существования этого контекста. Какую ценность несет этот контекст, кто получит выгоду, и как она обеспечивается? Сюда же можно записать бизнес-драйверы.
Стратегическая классификация, из трех частей:
💎 Уникальность — насколько этот контекст важен для успеха организации?
Он основной (core), то есть обеспечивает ключевое преимущество — или, как на английский манер говорят, является дифференциатором, отличает ваш бизнес от других? Или поддерживающий — обязательный для деятельности, но не уникальный? Или типовой (generic) — такой же, как у других компаний, ничего специфического?
⚙️ Роль в бизнес-модели:
— генерация прибыли,
— повышение вовлеченности/виральности,
— предотвращение рисков (регуляторных, репутационных, ...)
— снижение расходов
📊 Стадия эволюции (по Wardley map):
— Зарождение
— Заказная разработка
— Готовый продукт
— Типовое решение (commodity)
Архетип домена (роль):
— Конструктор (нужен для создания чего-то, возможно — совместными усилиями, возможно — черновика какого-то объекта)
— Исполнитель (выполняет или поддерживает исполнение бизнес-процесса)
— Аудитор (отслеживает выполнение)
— Контролер (принимает решение о возможности выполнения следующего шага, утверждает)
— Блюститель (Enforcer; принуждает другие контексты выполнить определенные операции в соответствии с внешними бизнес-правилами)
— Переводчик (переводит между разными "бизнес-языками")
— Шлюз (контролирует границы и внешние взаимодействия; может совмещаться с ролью переводчика)
— Пузырь (экранирует легаси-систему до её вывода)
— Воронка/трубопровод (перекачивает данные/документы из одного контекста в другой с обработкой)
— Аналитика (собирает и обобщает данные)
Язык домена: какие в этом контексте есть понятия и термины?
Входящие коммуникации: кто в этот контекст посылает сообщения, и какие? Это могут быть другие контексты, пользователи или устройства пользователей, существующие системы. Контексты с точки зрения коммуникаций делятся на восходящие (upstream) и нисходящие (downstream) — восходящие предоставляют информацию/сервисы и публикуют события, а нисходящие используют информацию и потребляют события.
У взаимодействий тоже есть свои типы, или паттерны мэппинга контекста:
— OHS, Open-host Service — контекст предоставляет одинаковые услуги всем, кому они нужны. Он не подстраивается под каждого клиента. Это upstream-контекст.
— CF, Conformist — паттерн для downstream-контекста: он подстраивается под язык upstream.
— ACL, Anticorruption layer — изолирующий слой для downstream-контекста, фильтрующий всю возможную "порчу", поступающую извне.
— SK, Shared Kernel — два контекста разделяют одну (компактную) модель. Создает зацепление, но облегчает понимание.
— PNR, Partnership — это больше про взаимодействие команд, когда они совместно согласуют взаимодействия (каждый может подвинуться)
— Customer / Supplier — отношения upstream/downstream, но, в отличие от OHS, upstream (supplier) зависит от cutomer'а, и учитывает его потребности в своей логике развития.
— PL, Published Language — дополнительный паттерн, определяющий специальный язык/формат для обмена. Типа vCard, или iCalendar, или какой-нибудь FHIR.
По паттерну взаимодействия тоже можно принять решение и зафиксировать на шаблоне.
Так же заполняется часть с исходящими коммуникациями, только теперь наш контекст будет upstream. Входящие и исходящие коммуникации удобно группировать в дорожки — юскейсы.
Бизнес-решения: какие приняты решения, политики и бизнес-правила.
Предположения: какими бизнес-предположениями в отношении контекста мы руководствовались.
Метрики верификации: у нас же были драйверы и предположения, а как мы измерим успех?
Открытые вопросы: что ещё нужно выяснить?
Я не знаю, как это заполняют программисты, но, кажется, это типовые вопросы для аналитика. Причем даже без связи с DDD, такие вопросы стоит задать при работе над любой задачей.
Разделы:
Название
Смысл (Purpose) — бизнес-смысл существования этого контекста. Какую ценность несет этот контекст, кто получит выгоду, и как она обеспечивается? Сюда же можно записать бизнес-драйверы.
Стратегическая классификация, из трех частей:
Он основной (core), то есть обеспечивает ключевое преимущество — или, как на английский манер говорят, является дифференциатором, отличает ваш бизнес от других? Или поддерживающий — обязательный для деятельности, но не уникальный? Или типовой (generic) — такой же, как у других компаний, ничего специфического?
— генерация прибыли,
— повышение вовлеченности/виральности,
— предотвращение рисков (регуляторных, репутационных, ...)
— снижение расходов
— Зарождение
— Заказная разработка
— Готовый продукт
— Типовое решение (commodity)
Архетип домена (роль):
— Конструктор (нужен для создания чего-то, возможно — совместными усилиями, возможно — черновика какого-то объекта)
— Исполнитель (выполняет или поддерживает исполнение бизнес-процесса)
— Аудитор (отслеживает выполнение)
— Контролер (принимает решение о возможности выполнения следующего шага, утверждает)
— Блюститель (Enforcer; принуждает другие контексты выполнить определенные операции в соответствии с внешними бизнес-правилами)
— Переводчик (переводит между разными "бизнес-языками")
— Шлюз (контролирует границы и внешние взаимодействия; может совмещаться с ролью переводчика)
— Пузырь (экранирует легаси-систему до её вывода)
— Воронка/трубопровод (перекачивает данные/документы из одного контекста в другой с обработкой)
— Аналитика (собирает и обобщает данные)
Язык домена: какие в этом контексте есть понятия и термины?
Входящие коммуникации: кто в этот контекст посылает сообщения, и какие? Это могут быть другие контексты, пользователи или устройства пользователей, существующие системы. Контексты с точки зрения коммуникаций делятся на восходящие (upstream) и нисходящие (downstream) — восходящие предоставляют информацию/сервисы и публикуют события, а нисходящие используют информацию и потребляют события.
У взаимодействий тоже есть свои типы, или паттерны мэппинга контекста:
— OHS, Open-host Service — контекст предоставляет одинаковые услуги всем, кому они нужны. Он не подстраивается под каждого клиента. Это upstream-контекст.
— CF, Conformist — паттерн для downstream-контекста: он подстраивается под язык upstream.
— ACL, Anticorruption layer — изолирующий слой для downstream-контекста, фильтрующий всю возможную "порчу", поступающую извне.
— SK, Shared Kernel — два контекста разделяют одну (компактную) модель. Создает зацепление, но облегчает понимание.
— PNR, Partnership — это больше про взаимодействие команд, когда они совместно согласуют взаимодействия (каждый может подвинуться)
— Customer / Supplier — отношения upstream/downstream, но, в отличие от OHS, upstream (supplier) зависит от cutomer'а, и учитывает его потребности в своей логике развития.
— PL, Published Language — дополнительный паттерн, определяющий специальный язык/формат для обмена. Типа vCard, или iCalendar, или какой-нибудь FHIR.
По паттерну взаимодействия тоже можно принять решение и зафиксировать на шаблоне.
Так же заполняется часть с исходящими коммуникациями, только теперь наш контекст будет upstream. Входящие и исходящие коммуникации удобно группировать в дорожки — юскейсы.
Бизнес-решения: какие приняты решения, политики и бизнес-правила.
Предположения: какими бизнес-предположениями в отношении контекста мы руководствовались.
Метрики верификации: у нас же были драйверы и предположения, а как мы измерим успех?
Открытые вопросы: что ещё нужно выяснить?
Я не знаю, как это заполняют программисты, но, кажется, это типовые вопросы для аналитика. Причем даже без связи с DDD, такие вопросы стоит задать при работе над любой задачей.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤2👌1
Про аналитиков мы уже говорили, а откуда взялись архитекторы ПО?
Термин "архитектура компьютера" вбросил Фред Брукс (руководитель проекта создания OS/360) и Lyle R. Johnson примерно в 1959 году. Определял он её как "то, что нужно знать пользователю". Пользователями тогда называли прикладных программистов.
Об архитектуре программ тогда речь не шла; идея, что разные части программы неплохо как-то логично организовать: структурное программирование только-только появилась.
В 1975 вышла книга Брукса "Мифический человеко-месяц", в которой он ввел понятие "программной системы", в отличие от отдельной программы. В том же году Frank DeRemer и Hans Kron опубликовали статьи "Программирование в большом [масштабе] против программирования в малом". В малом — это как раз про написание одиночной программы одним программистом, а "в большом" — как раз проектирование систем, состоящих из многих частей, написанных разными людьми. Но и это не привело к появлению профессии архитектора. Скорее стали разделять кодеров и программистов.
Прошло ещё 15 лет, прежде чем об архитектуре ПО заговорили, как об отдельном предмете. Первая книга про архитектуру появилась в 1990: Laurence J. Best, Application Architecture: Modern Large-Scale Information Processing. Речь тогда в основном шла о переиспользовании компонент, все носились с этой идеей переиспользования и выделения типовых объектов в объектно-ориентированных системах. Была даже целая объектно-ориентированная операционная система — OS/2 от IBM (проигравшая соревнование с Windows, но ставшая культовой в определенных кругах).
В 1992 опубликована статья Dewayne E. Perry и Alexander L. Wolf 'Foundations for the Study of Software Architecture', в которой обсуждается разница между архитектурой и дизайном, а также вводится формула:
Программная архитектура = {Элементы, Формы, Обоснования},
где Элементы делятся на элементы обработки, элементы данных и элементы связи,
а Формы — на взвешенные свойства элементов/системы и отношения между элементами.
В 1993 вышла работа 'An Introduction to Software Architecture' David Garlan и Mary Shaw, а 1996 их же книга 'Software Architecture: Perspectives on an Emerging Discipline' (перспективы зарождающейся дисциплины). Во "Введении в программную архитектуру" уже были перечислены такие архитектурные стили, как "трубы и фильтры", объектно-ориентированный стиль, событийно-ориентированный стиль, слоистые системы и т.д. (так что если вы видите такой список в каком-нибудь курсе или статье — помните, это список из 1993 года!) Основным вопросом было — кто в какой момент кого вызывает.
В 1995 году началась разработка стандарта IEEE 1471 Recommended Practice for Architectural Description for Software-Intensive Systems (будущий ISO 42010). Он вводил идею множества стейкхолдеров, точек зрения и архитектурных представлений. Для каждого архитектура — что-то своё, архитектура в глазах смотрящего.
Параллельно развивались подходы к оценке качества программного продукта: ISO 9126 впервые вышел в 1991 году. К началу 2000-х два направления сошлись: выяснилось, что на качество влияет как раз архитектура. Функции-то система будет выполнять с любой архитектурой, а вот для обеспечения разнообразных -ilities нужно подумать над внутренним устройством. Но это всё было не очень принципиально — пользователей было мало, данных было не очень много, вопросы если и возникали — то только в производительности или в скорости создания/изменения систем.
Звездный час для архитекторов наступил только в конце 2000-х, с расцветом веба — тут мы увидели такие нагрузки и такое количество данных, которых до этого никто никогда не видел. А вместе с ними — распределенные системы и жесткие требования по скорости обновления (TTM). И тогда появились специальные люди, определяющие основные развилки. Впрочем, на самом деле их настолько мало, что US Bureau of Labor Statistics отдельной роли архитектора вообще не выделяет, у них это обобщенные Software Developers, Quality Assurance Analysts and Testers. Так что, возможно, архитектор — это такая же специфическая для РФ роль, как и системный аналитик.
Термин "архитектура компьютера" вбросил Фред Брукс (руководитель проекта создания OS/360) и Lyle R. Johnson примерно в 1959 году. Определял он её как "то, что нужно знать пользователю". Пользователями тогда называли прикладных программистов.
Об архитектуре программ тогда речь не шла; идея, что разные части программы неплохо как-то логично организовать: структурное программирование только-только появилась.
В 1975 вышла книга Брукса "Мифический человеко-месяц", в которой он ввел понятие "программной системы", в отличие от отдельной программы. В том же году Frank DeRemer и Hans Kron опубликовали статьи "Программирование в большом [масштабе] против программирования в малом". В малом — это как раз про написание одиночной программы одним программистом, а "в большом" — как раз проектирование систем, состоящих из многих частей, написанных разными людьми. Но и это не привело к появлению профессии архитектора. Скорее стали разделять кодеров и программистов.
Прошло ещё 15 лет, прежде чем об архитектуре ПО заговорили, как об отдельном предмете. Первая книга про архитектуру появилась в 1990: Laurence J. Best, Application Architecture: Modern Large-Scale Information Processing. Речь тогда в основном шла о переиспользовании компонент, все носились с этой идеей переиспользования и выделения типовых объектов в объектно-ориентированных системах. Была даже целая объектно-ориентированная операционная система — OS/2 от IBM (проигравшая соревнование с Windows, но ставшая культовой в определенных кругах).
В 1992 опубликована статья Dewayne E. Perry и Alexander L. Wolf 'Foundations for the Study of Software Architecture', в которой обсуждается разница между архитектурой и дизайном, а также вводится формула:
Программная архитектура = {Элементы, Формы, Обоснования},
где Элементы делятся на элементы обработки, элементы данных и элементы связи,
а Формы — на взвешенные свойства элементов/системы и отношения между элементами.
В 1993 вышла работа 'An Introduction to Software Architecture' David Garlan и Mary Shaw, а 1996 их же книга 'Software Architecture: Perspectives on an Emerging Discipline' (перспективы зарождающейся дисциплины). Во "Введении в программную архитектуру" уже были перечислены такие архитектурные стили, как "трубы и фильтры", объектно-ориентированный стиль, событийно-ориентированный стиль, слоистые системы и т.д. (так что если вы видите такой список в каком-нибудь курсе или статье — помните, это список из 1993 года!) Основным вопросом было — кто в какой момент кого вызывает.
В 1995 году началась разработка стандарта IEEE 1471 Recommended Practice for Architectural Description for Software-Intensive Systems (будущий ISO 42010). Он вводил идею множества стейкхолдеров, точек зрения и архитектурных представлений. Для каждого архитектура — что-то своё, архитектура в глазах смотрящего.
Параллельно развивались подходы к оценке качества программного продукта: ISO 9126 впервые вышел в 1991 году. К началу 2000-х два направления сошлись: выяснилось, что на качество влияет как раз архитектура. Функции-то система будет выполнять с любой архитектурой, а вот для обеспечения разнообразных -ilities нужно подумать над внутренним устройством. Но это всё было не очень принципиально — пользователей было мало, данных было не очень много, вопросы если и возникали — то только в производительности или в скорости создания/изменения систем.
Звездный час для архитекторов наступил только в конце 2000-х, с расцветом веба — тут мы увидели такие нагрузки и такое количество данных, которых до этого никто никогда не видел. А вместе с ними — распределенные системы и жесткие требования по скорости обновления (TTM). И тогда появились специальные люди, определяющие основные развилки. Впрочем, на самом деле их настолько мало, что US Bureau of Labor Statistics отдельной роли архитектора вообще не выделяет, у них это обобщенные Software Developers, Quality Assurance Analysts and Testers. Так что, возможно, архитектор — это такая же специфическая для РФ роль, как и системный аналитик.
👍13❤4🔥1
Статья Дуэйна Перри и Александра Вольфа 'Foundations for the Study of Software Architecture' 1992 года достойна отдельного поста. Это одна из самых цитируемых работ по программной инженерии за всю историю.
В ней много интересных тезисов. Например, что архитектура ПО больше всего похожа на архитектуру зданий: требует нескольких отдельных видов, отражающих разные аспекты одной системы (или здания); имеет выраженные архитектурные стили, определяющие используемые элементы и их возможные связи; при этом стили связаны с инженерными принципами (то, что ты строишь, зависит от того, как ты строишь) и с материалом (...и из чего ты строишь).
Дальше они характеризуют разные уровни рассмотрения:
— требования определяют информацию, процессы её обработки, а также характеристики этой информации и процессов обработки, требуемые пользователям;
— архитектура занимается выбором архитектурных элементов, их взаимодействий, и ограничениями, накладываемыми на эти элементы и взаимодействия. Всё это нужно для создания основы, в рамках которой можно удовлетворить требования и которая послужит базой для проектирования.
— проектирование (дизайн) касается модульности, детальных интерфейсов элементов, алгоритмов и процедур, а также типов данных, необходимых для поддержки архитектуры и удовлетворения требований.
— реализация связана с представлением алгоритмов и типов данных, которые удовлетворяют проекту, архитектуре и требованиям. (Видимо, "представлением в виде кода")
Тут авторы оговариваются, что не во всех системах нужны все уровни, и иногда можно просто начать программировать (например, в проектах с искусственным интеллектом — напомню, это 1992 год!)
Распределение по уровням выглядит логично: сначала требования; потом выбор архитектуры, в которой, как кажется, можно реализовать эти требования; потом конкретный проект в выбранной архитектуре; и, наконец, реализация. Так что архитектор должен заниматься проектированием архитектуры, созданием основы. А конкретным дизайном может кто-то другой заняться. И если, по случайности, проектированием занимается архитектор — он просто выполняет другую роль в этот момент.
Итак, авторы определяют архитектуру через три понятия:
Software Architecture = { Elements, Form, Rationale }
Элементы архитектуры делятся на три класса:
* элементы обработки
* элементы данных
* соединительные элементы
Форма состоит из взвешенных свойств и отношений. Взвешенных — потому что не все свойства одинаково важны для конкретной системы (в соответствии с требованиями). Свойства ограничивают выбор архитектурных элементов. Отношения ограничивают "размещение" архитектурных элементов — то, где они расположены и как они связаны между собой.
Наконец, неотъемлемой, самой важной частью архитектуры является обоснование различных решений, принятых при определении архитектуры. Обоснование отражает мотивацию выбора архитектурного стиля, выбора элементов, и формы. Таким образом, главный документ архитектуры — не схема соединений конкретной системы (это проект). Главный документ — описание базовых принципов и принятых решений, то есть ADR.
Собственно, архитектурный стиль — это некий набор готовых решений, которые умные люди уже сделали за вас. Две главные проблемы архитектуры проявляются при изменении систем: эрозия и дрейф. Эрозия — это нарушение принципов определенной архитектуры или выбранного архитектурного стиля, а дрейф — когда сами принципы уже невозможно определить.
Интересно, как они определяют свойства — как состояния данных или результата обработки. То есть система описывается топологией связей и вот этими свойствами, практически через машину состояний. Это интересный подход, сегодня кажется утерянный. Мы моделируем потоки данных, процессы и команды, события, но архитекторы редко говорят про состояния (даже когда упоминают REST, который, по идее, должен как раз вокруг состояний строиться). А сложность архитектуры определяется как раз через сложность нотации, требуемой для описания состояний системы.
В ней много интересных тезисов. Например, что архитектура ПО больше всего похожа на архитектуру зданий: требует нескольких отдельных видов, отражающих разные аспекты одной системы (или здания); имеет выраженные архитектурные стили, определяющие используемые элементы и их возможные связи; при этом стили связаны с инженерными принципами (то, что ты строишь, зависит от того, как ты строишь) и с материалом (...и из чего ты строишь).
Дальше они характеризуют разные уровни рассмотрения:
— требования определяют информацию, процессы её обработки, а также характеристики этой информации и процессов обработки, требуемые пользователям;
— архитектура занимается выбором архитектурных элементов, их взаимодействий, и ограничениями, накладываемыми на эти элементы и взаимодействия. Всё это нужно для создания основы, в рамках которой можно удовлетворить требования и которая послужит базой для проектирования.
— проектирование (дизайн) касается модульности, детальных интерфейсов элементов, алгоритмов и процедур, а также типов данных, необходимых для поддержки архитектуры и удовлетворения требований.
— реализация связана с представлением алгоритмов и типов данных, которые удовлетворяют проекту, архитектуре и требованиям. (Видимо, "представлением в виде кода")
Тут авторы оговариваются, что не во всех системах нужны все уровни, и иногда можно просто начать программировать (например, в проектах с искусственным интеллектом — напомню, это 1992 год!)
Распределение по уровням выглядит логично: сначала требования; потом выбор архитектуры, в которой, как кажется, можно реализовать эти требования; потом конкретный проект в выбранной архитектуре; и, наконец, реализация. Так что архитектор должен заниматься проектированием архитектуры, созданием основы. А конкретным дизайном может кто-то другой заняться. И если, по случайности, проектированием занимается архитектор — он просто выполняет другую роль в этот момент.
Итак, авторы определяют архитектуру через три понятия:
Software Architecture = { Elements, Form, Rationale }
Элементы архитектуры делятся на три класса:
* элементы обработки
* элементы данных
* соединительные элементы
Форма состоит из взвешенных свойств и отношений. Взвешенных — потому что не все свойства одинаково важны для конкретной системы (в соответствии с требованиями). Свойства ограничивают выбор архитектурных элементов. Отношения ограничивают "размещение" архитектурных элементов — то, где они расположены и как они связаны между собой.
Наконец, неотъемлемой, самой важной частью архитектуры является обоснование различных решений, принятых при определении архитектуры. Обоснование отражает мотивацию выбора архитектурного стиля, выбора элементов, и формы. Таким образом, главный документ архитектуры — не схема соединений конкретной системы (это проект). Главный документ — описание базовых принципов и принятых решений, то есть ADR.
Собственно, архитектурный стиль — это некий набор готовых решений, которые умные люди уже сделали за вас. Две главные проблемы архитектуры проявляются при изменении систем: эрозия и дрейф. Эрозия — это нарушение принципов определенной архитектуры или выбранного архитектурного стиля, а дрейф — когда сами принципы уже невозможно определить.
Интересно, как они определяют свойства — как состояния данных или результата обработки. То есть система описывается топологией связей и вот этими свойствами, практически через машину состояний. Это интересный подход, сегодня кажется утерянный. Мы моделируем потоки данных, процессы и команды, события, но архитекторы редко говорят про состояния (даже когда упоминают REST, который, по идее, должен как раз вокруг состояний строиться). А сложность архитектуры определяется как раз через сложность нотации, требуемой для описания состояний системы.
❤7🔥4👍3
Нужно, наверное, какие-то итоги года подвести.
Итоги такие:
1. Канал немного не дотянул до 10 тыс.; число, конечно, символическое, но было бы приятно. В целом заметно замедление роста — то ли в алгоритмах рекомендаций что-то поменялось, то ли я стал писать про абстрактные вещи, не особо интересные. Оторвался от потребностей аудитории — а что, вполне возможно.
2. На рынке стал отчетливо виден спад, чтобы не сказать кризис. Найти работу стало сложнее. Проекты сжимаются, денег ощутимо меньше. И не думаю, что это как-то связано с ИИ, причины совсем в другом. Учебные группы набираются трудно, столько отмен и переносов не было раньше. На уровне ощущений — сейчас, кажется, должны быть востребованы менее дорогие форматы (но очень конкретные, которые дадут пользу прямо сейчас — либо с сохранением работы, либо с поиском).
3. О чем писал:
* Сильно обновил карту интеграций: раз и два
* С какими видами неопределенности работает аналитик и что с ними делать?
* Экономическая обоснованность автоматизации задач
* Шпаргалка по структуре http-запроса (надо бы сделать всё-таки сборник "интеграции в картинках")
* Вытащил в наглядную таблицу пример стоимости масштабирования
* Перевел несколько комиксов про разработку
* Написал про формулу Пуассона для расчета нагрузки в интеграциях
* Немного поборолся с распространенными мифами: про снижение неопределенности к концу проекта (Cone of uncertainty) и про стоимость исправления ошибки в зависимости от стадии обнаружения
* Запостил "Пирамиду требований", которую обычно на тренингах рисую
* Написал про эмоциональный компонент JTBD
* И про "Ясный язык"
* Про неизбежность диктатора при принятии коллективных решений и преодоление этой неизбежности
* Провел небольшое исследование — про среду в компаниях по методу Ясвина
* Про радар выбора процесса разработки — подходит ли для вашего проекта Agile?
* Какие решения и в каком виде можно передавать ИИ?
* Нашел граф со всеми возможными нефункциональными требованиями
* А ещё — каталог паттернов миграции со старой системы на новую
* И шаблон для PRD
* Сходил на новые конференции от JUG.ru — BiasConf и InBetween
* Пошутил про приколы интеграции (не протоколы!)
* Подсмотрел, как живут продакты (по отчету Atlassian)
* Поучаствовал в проектировании и анализе исследования системных аналитиков
* Завел отдельный канал про цифровизацию образования
* Написал про "Дома качества" — методику связывания функциональных и нефункциональных свойств с конструктивными особенностями и продуктовыми метриками
* Затеял несколько постов про DDD
* И вообще про роли аналитика и архитектора: раз, два и три
* А также сделал чеклист для выявления микросервисов и написал про канвас для ограниченных контекстов
Тема проектирования микросервисов получила развитие в виде курса, который уже один раз провел в декабре, и, надеюсь, буду повторять.
А вообще — много о чем за год удалось написать, хватает уже материала на книгу? "Современные методики анализа и проектирования систем"? Звучит, как учебник. Или "Записки аналитика"? ("у изголовья", подсказывает ассоциативная память).
В общем, не переключайтесь, в следующем году постараюсь для вас придумать что-нибудь менее философское и более прагматичное, а всем подписчикам желаю только самого лучшего — интересной работы, финансовой независимости, поддержки и понимания со стороны коллег и руководителей, уверенности в завтрашнем дне и профессионального роста! Ну и спокойствия ещё, всем нам оно необходимо.
С наступающим Новым годом!
🎄 🎁 🥂 🎆
Итоги такие:
1. Канал немного не дотянул до 10 тыс.; число, конечно, символическое, но было бы приятно. В целом заметно замедление роста — то ли в алгоритмах рекомендаций что-то поменялось, то ли я стал писать про абстрактные вещи, не особо интересные. Оторвался от потребностей аудитории — а что, вполне возможно.
2. На рынке стал отчетливо виден спад, чтобы не сказать кризис. Найти работу стало сложнее. Проекты сжимаются, денег ощутимо меньше. И не думаю, что это как-то связано с ИИ, причины совсем в другом. Учебные группы набираются трудно, столько отмен и переносов не было раньше. На уровне ощущений — сейчас, кажется, должны быть востребованы менее дорогие форматы (но очень конкретные, которые дадут пользу прямо сейчас — либо с сохранением работы, либо с поиском).
3. О чем писал:
* Сильно обновил карту интеграций: раз и два
* С какими видами неопределенности работает аналитик и что с ними делать?
* Экономическая обоснованность автоматизации задач
* Шпаргалка по структуре http-запроса (надо бы сделать всё-таки сборник "интеграции в картинках")
* Вытащил в наглядную таблицу пример стоимости масштабирования
* Перевел несколько комиксов про разработку
* Написал про формулу Пуассона для расчета нагрузки в интеграциях
* Немного поборолся с распространенными мифами: про снижение неопределенности к концу проекта (Cone of uncertainty) и про стоимость исправления ошибки в зависимости от стадии обнаружения
* Запостил "Пирамиду требований", которую обычно на тренингах рисую
* Написал про эмоциональный компонент JTBD
* И про "Ясный язык"
* Про неизбежность диктатора при принятии коллективных решений и преодоление этой неизбежности
* Провел небольшое исследование — про среду в компаниях по методу Ясвина
* Про радар выбора процесса разработки — подходит ли для вашего проекта Agile?
* Какие решения и в каком виде можно передавать ИИ?
* Нашел граф со всеми возможными нефункциональными требованиями
* А ещё — каталог паттернов миграции со старой системы на новую
* И шаблон для PRD
* Сходил на новые конференции от JUG.ru — BiasConf и InBetween
* Пошутил про приколы интеграции (не протоколы!)
* Подсмотрел, как живут продакты (по отчету Atlassian)
* Поучаствовал в проектировании и анализе исследования системных аналитиков
* Завел отдельный канал про цифровизацию образования
* Написал про "Дома качества" — методику связывания функциональных и нефункциональных свойств с конструктивными особенностями и продуктовыми метриками
* Затеял несколько постов про DDD
* И вообще про роли аналитика и архитектора: раз, два и три
* А также сделал чеклист для выявления микросервисов и написал про канвас для ограниченных контекстов
Тема проектирования микросервисов получила развитие в виде курса, который уже один раз провел в декабре, и, надеюсь, буду повторять.
А вообще — много о чем за год удалось написать, хватает уже материала на книгу? "Современные методики анализа и проектирования систем"? Звучит, как учебник. Или "Записки аналитика"? ("у изголовья", подсказывает ассоциативная память).
В общем, не переключайтесь, в следующем году постараюсь для вас придумать что-нибудь менее философское и более прагматичное, а всем подписчикам желаю только самого лучшего — интересной работы, финансовой независимости, поддержки и понимания со стороны коллег и руководителей, уверенности в завтрашнем дне и профессионального роста! Ну и спокойствия ещё, всем нам оно необходимо.
С наступающим Новым годом!
Please open Telegram to view this post
VIEW IN TELEGRAM
2🎉58❤33🔥12🎄4🥰3
С наступившим Новым годом!
В одном из новогодних обращений услышал: а ведь уже прошла четверть XXI века! Те, кто постарше (как я), помнят, что 21 век казался каким-то фантастическим. Ну он такой и есть! Вокруг нвс сплошная фантастика: у всех "персональные коммуникаторы", мы погружены в виртуальные миры, звоним с видео в любую точку мира, по улицам ездят роботы и машины без водителей, мы каждый день разговариваем с искусственным интеллектом, всерьёз собираемся колонизировать Луну и Марс, почти не используем наличные деньги, операции делают роботы и т.д. Фантастика!
Ну а для меня самый приятный символический подарок — достижение каналом 10k подписчиков, это круто!
Ну и традиционно — вам подарок от меня: пишите в комментариях о своих каналах, а я потом сделаю общий пост с упоминанием всех! Всем пишущим и снимающим — роста в этом году!
В одном из новогодних обращений услышал: а ведь уже прошла четверть XXI века! Те, кто постарше (как я), помнят, что 21 век казался каким-то фантастическим. Ну он такой и есть! Вокруг нвс сплошная фантастика: у всех "персональные коммуникаторы", мы погружены в виртуальные миры, звоним с видео в любую точку мира, по улицам ездят роботы и машины без водителей, мы каждый день разговариваем с искусственным интеллектом, всерьёз собираемся колонизировать Луну и Марс, почти не используем наличные деньги, операции делают роботы и т.д. Фантастика!
Ну а для меня самый приятный символический подарок — достижение каналом 10k подписчиков, это круто!
Ну и традиционно — вам подарок от меня: пишите в комментариях о своих каналах, а я потом сделаю общий пост с упоминанием всех! Всем пишущим и снимающим — роста в этом году!
❤29🎉7🔥5👍1
Я слежу за статьями Пола Ральфа (который писал про иллюзию требований), но эта ветка исследований немного заглохла. Зато есть свежая статья: "Влияние генеративного ИИ на креативность в разработке ПО".
Там большой коллектив авторов, и это скорее призыв к дальнейшим исследованиям, как раз в тему в начале года (хотя опубликована она ещё в мае 2025). В каком-то смысле это всё-таки продолжение — ведь то, что мы делаем при создании программных продуктов, это, конечно, никакие не требования, а идеи. Идеи, которые мы придумываем, и креативность тут играет чуть ли не большую роль, чем продуктивность.
Авторы определяют креативность как "Способность придумывать идеи или создавать артефакты, которые являются новыми, неожиданными и ценными".
Дальше они раскладывают креативность по модели 4P: Person, Product, Process и Press (давление окружения) и пытаются анализировать влияние генеративного ИИ с позиций тетрадного анализа Маршалла Маклюэна — это, напомню, один из самых влиятельных философов XX века, описавший современные медиа и их влияние на общество. Тетрада задает рамку анализа новой технологии — какие практики технология усиливает, какие делает устаревшими, какие наоборот возвращает из забытья, и к чему приводит в пределе? (По Маклюэну — к противоположности)
Вот что получилось.
Влияние на личную креативность:
Усиливает:
- Генерацию идей
- Объединение идей из разных областей
- Быструю проверку/отладку
- Тщательный подход
- Понимание стейкхолдеров
- Выбор подходящего варианта
Делает устаревшим и ненужным:
- Различие в личных качествах
- Глубокое мышление
- Рефлексию
- Экспертизу
- Менторинг
Возвращает:
- Эскизное проектирование, наброски
- Верификацию
- Творческую работу
Приводит к обратному:
- Штамповке типовых решений
- Исключению анализа вариантов
- Потере креативных навыков
Влияние на продукт:
Усиливает:
- Непрерывное улучшение
- Кастомизированный UX
- Учет обратной связи
- Возможность делать "невозможные вещи"
- Радикальные инновации
Делает устаревшим:
- Стандартные решения
- Фреймворки
- Промежуточные артефакты проектирования
- Графический дизайн и элементы оформления
- Специализированные артефакты (музыку, звуки, дизайн уровней, баз данных, интерфейсы и т.п.)
Возвращает:
- Паттерны и стили
- Старые приемы проектирования и решения
- "Аналоговые" методы проектирования — на карточках, на бумаге
Приводит к обратному:
- Эффекту "эхо-камеры": подтверждение предвзятости, ограничение вариантов
- Однообразные продукты
- Чрезмерно креативным, вычурным продуктам
- Предвзятости
- Вредным продуктам, черному UX, эксплуатации аддикций
Влияние на процессы:
Усиливает:
- Обыденные задачи
- Быстрое прототипирование
- Коллаборацию
- Креативность по запросу
- Модерацию/фасилитацию
Делает устаревшим:
- Мозговые штурмы
- Специализацию, разделение ролей
- Техники проверки дизайна (изучение пользователей, фокус-группы, мысленное пошаговое прохождение интерфейсов и т.п.)
- Экспертов по креативным методикам и проектированию
Возвращает (тут всё в противодействие):
- Парное программирование
- Техники генерации идей (мозговые штурмы, дизайн-спринты)
- Аналоговые техники творчества (лего, бумажное прототипирование и т.п.)
- Ручные исследования пользователей
- Изучение других предметных областей
Приводит к обратному:
- Потере интуиции
- Потере доверия
- Потере работы
- Разложению ролей специалистов по созданию ПО
- Кафкианской безответственности
Влияние на среду:
Усиливает:
- Поиск контекстной информации
- Вдохновение окружающей средой
- Сборку команд
- Эффективность в виртуальных средах
- Психологическую безопасность
- Голос разума
- Готовность принимать риски
Делает устаревшим:
- Доски, флипчарты, стикеры
- Кубиклы
- Фиксированные пространства
- Офисы вообще
- Коллег
Возвращает:
- Креативность в движении
- Поддерживающее руководство
Приводит к обратному:
- Саботажу
- Изоляции
- Снижении гордости за результаты своего труда
- Давлению руководства
- Невозможности высказаться
- Ненужности креативности
Ну что, как вам такие предположения?
Там большой коллектив авторов, и это скорее призыв к дальнейшим исследованиям, как раз в тему в начале года (хотя опубликована она ещё в мае 2025). В каком-то смысле это всё-таки продолжение — ведь то, что мы делаем при создании программных продуктов, это, конечно, никакие не требования, а идеи. Идеи, которые мы придумываем, и креативность тут играет чуть ли не большую роль, чем продуктивность.
Авторы определяют креативность как "Способность придумывать идеи или создавать артефакты, которые являются новыми, неожиданными и ценными".
Дальше они раскладывают креативность по модели 4P: Person, Product, Process и Press (давление окружения) и пытаются анализировать влияние генеративного ИИ с позиций тетрадного анализа Маршалла Маклюэна — это, напомню, один из самых влиятельных философов XX века, описавший современные медиа и их влияние на общество. Тетрада задает рамку анализа новой технологии — какие практики технология усиливает, какие делает устаревшими, какие наоборот возвращает из забытья, и к чему приводит в пределе? (По Маклюэну — к противоположности)
Вот что получилось.
Влияние на личную креативность:
Усиливает:
- Генерацию идей
- Объединение идей из разных областей
- Быструю проверку/отладку
- Тщательный подход
- Понимание стейкхолдеров
- Выбор подходящего варианта
Делает устаревшим и ненужным:
- Различие в личных качествах
- Глубокое мышление
- Рефлексию
- Экспертизу
- Менторинг
Возвращает:
- Эскизное проектирование, наброски
- Верификацию
- Творческую работу
Приводит к обратному:
- Штамповке типовых решений
- Исключению анализа вариантов
- Потере креативных навыков
Влияние на продукт:
Усиливает:
- Непрерывное улучшение
- Кастомизированный UX
- Учет обратной связи
- Возможность делать "невозможные вещи"
- Радикальные инновации
Делает устаревшим:
- Стандартные решения
- Фреймворки
- Промежуточные артефакты проектирования
- Графический дизайн и элементы оформления
- Специализированные артефакты (музыку, звуки, дизайн уровней, баз данных, интерфейсы и т.п.)
Возвращает:
- Паттерны и стили
- Старые приемы проектирования и решения
- "Аналоговые" методы проектирования — на карточках, на бумаге
Приводит к обратному:
- Эффекту "эхо-камеры": подтверждение предвзятости, ограничение вариантов
- Однообразные продукты
- Чрезмерно креативным, вычурным продуктам
- Предвзятости
- Вредным продуктам, черному UX, эксплуатации аддикций
Влияние на процессы:
Усиливает:
- Обыденные задачи
- Быстрое прототипирование
- Коллаборацию
- Креативность по запросу
- Модерацию/фасилитацию
Делает устаревшим:
- Мозговые штурмы
- Специализацию, разделение ролей
- Техники проверки дизайна (изучение пользователей, фокус-группы, мысленное пошаговое прохождение интерфейсов и т.п.)
- Экспертов по креативным методикам и проектированию
Возвращает (тут всё в противодействие):
- Парное программирование
- Техники генерации идей (мозговые штурмы, дизайн-спринты)
- Аналоговые техники творчества (лего, бумажное прототипирование и т.п.)
- Ручные исследования пользователей
- Изучение других предметных областей
Приводит к обратному:
- Потере интуиции
- Потере доверия
- Потере работы
- Разложению ролей специалистов по созданию ПО
- Кафкианской безответственности
Влияние на среду:
Усиливает:
- Поиск контекстной информации
- Вдохновение окружающей средой
- Сборку команд
- Эффективность в виртуальных средах
- Психологическую безопасность
- Голос разума
- Готовность принимать риски
Делает устаревшим:
- Доски, флипчарты, стикеры
- Кубиклы
- Фиксированные пространства
- Офисы вообще
- Коллег
Возвращает:
- Креативность в движении
- Поддерживающее руководство
Приводит к обратному:
- Саботажу
- Изоляции
- Снижении гордости за результаты своего труда
- Давлению руководства
- Невозможности высказаться
- Ненужности креативности
Ну что, как вам такие предположения?
🔥10❤8👏7
Так, что-то каникулы канала неожиданно затянулись. Уже и новый год прошел, и старый, и день святого Валентина, и китайский Новый год начался, совмещенный с Масленицей. Кажется, такой паузы я ещё не делал.
Заодно в очередной раз начались блокировки Телеграма, ну и вообще ситуация так себе: конференцию WAW в этом году тихо отменили, весеннего Flow не будет, ЛАФ возвращается к истокам — в Иваново и к формату "междусобойчик для своих". В общем, до отрасли докатился кризис. Время возможностей — нужно придумывать новые форматы и инструменты.
Но ничего, будем понемногуразбирать ёлку восстанавливать ритм публикаций. Нести свет просвещения в области системного анализа. Надеюсь, вы скучали.
Первый пост будет про перемены. Точнее, про изменения. Изменения требований. Я когда-то про это рассказывал, но радикально заявлял, что требования не меняются. Вот давайте посмотрим.
Заодно в очередной раз начались блокировки Телеграма, ну и вообще ситуация так себе: конференцию WAW в этом году тихо отменили, весеннего Flow не будет, ЛАФ возвращается к истокам — в Иваново и к формату "междусобойчик для своих". В общем, до отрасли докатился кризис. Время возможностей — нужно придумывать новые форматы и инструменты.
Но ничего, будем понемногу
Первый пост будет про перемены. Точнее, про изменения. Изменения требований. Я когда-то про это рассказывал, но радикально заявлял, что требования не меняются. Вот давайте посмотрим.
👍23❤4🕊3
Помните миф о кратном удорожании исправления дефектов на поздних стадиях разработки, в 100 и 1000 раз? Но нас в первую очередь интересует разработка требований, что тут будет дефектом?
Можно отследить изменения требований, их источники и влияние на проект.
И тут есть исследование 2011 года 'Software Requirements Change Taxonomy: Evaluation by Case Study' — "Таксономия изменений требований: оценка на основе кейса".
Авторы указывают следующие источники изменений в требованиях:
* Рынок (включая сюда регуляторные требования);
* Организация-потребитель — изменения, связанные со сменой стратегического направления одного из потребителей / изменения договоров / политического климата;
* Концепция проекта — поменялась решаемая проблема, направление развития продукта, приоритеты, стейкхолдеры или процессы;
* Спецификация — уточнение спецификации для устранения неопределенности, двусмысленности, несогласованности, повышения понимания (это как раз можно отнести к дефектам требований);
* Техническое решение — изменения, отражающие технические ограничения, принципиально новый дизайн или элегантность решения.
К внутренним причинам можно отнести только спецификацию — остальное меняется из-за внешних факторов.
В статье рассмотрен один проект из британского госсектора, стоимостью более миллиона фунтов (45-50 млн. руб по курсу 2010 г.), выполненный по водопадному подходу (был конкурс и внешний подрядчик) и длившийся примерно полтора года — в общем, похоже на довольно типовой проект.
Всего в требования было внесено 282 изменения: 67 на этапе сбора, 97 — при проектировании и разработке, 9 на этапе системного тестирования и 109 на этапе приемки пользователями.
По источникам на разных этапах они распределились так:
— этап требований: 30 — организация; 22 — спецификация; 15 — концепция.
— этап разработки: 58 — спецификация; 33 — решение; 4 — организация; по 1 — концепция и рынок.
— этап системного тестирования: 5 — спецификация; 3 — решение; 1 — концепция.
— этап приемки пользователями: 102 — спецификация; 7 — концепция.
В сумме, для 187 изменений из 282 источником была сама спецификация — её уточняли, дополняли и детализировали. На втором и третьем месте с небольшим разрывом между собой, но с огромным отставанием от спецификации — решение (36) и организация (34).
Так как это внутренний проект для одной организации, рынок тут практически не стал источником изменений (и в дальнейшем его не анализировали).
Дальше интереснее — нам важно не количество изменений, а их влияние на перерасход бюджета проекта, причем бюджета в человеко-днях. Ведь в деньгах можно намерять много чего (часто при измерении в деньгах сбиваются со стоимости исправления на стоимость последствий), а потраченные дополнительные человеко-дни — более объективная характеристика.
Стоимость задержки по источникам изменений и этапам, по убыванию:
1. Изменения спецификации на этапе приемки пользователями: 737 дней(!)
2. Изменения организации на этапе требований: 638 дней
3. Изменения концепции на этапе требований: 266 дней
4. Спецификация на этапе разработки: 222
5. Спецификация на этапе требований: 194
6. Концепция(!) на этапе приемки пользователями: 163 (!)
+ по мелочи
Изменения распределились в форме ванны: 46% (1097 человеко-дней) на этапе работы с требованиями и 38% (900 человеко-дней) — на этапе приемки.
Делаем вывод: отложенный фидбэк — путь к запланированным переделкам.
Изменение требований на этапе сбора требований — нормальный рабочий процесс, а вот на приемке этого хотелось бы избежать.
Но самое интересное — удельный вес изменений в зависимости от источника. Да, косяков в спецификации больше всего. Но в основном они мелкие: медианное значение — 4 дня. А вот одно изменение концепции на этапе приемки "стоит" 20 дней! Ещё дороже — изменения организации на этапе требований.
В общем, есть выбор — смерть от нескольких радикальных изменений концепции на последней стадии, или "смерть от тысячи порезов": мелких багов спеки. Это значит, что есть потенциал для улучшения — можно сэкономить целых 31%! Не сотни раз, но тоже немало.
Можно отследить изменения требований, их источники и влияние на проект.
И тут есть исследование 2011 года 'Software Requirements Change Taxonomy: Evaluation by Case Study' — "Таксономия изменений требований: оценка на основе кейса".
Авторы указывают следующие источники изменений в требованиях:
* Рынок (включая сюда регуляторные требования);
* Организация-потребитель — изменения, связанные со сменой стратегического направления одного из потребителей / изменения договоров / политического климата;
* Концепция проекта — поменялась решаемая проблема, направление развития продукта, приоритеты, стейкхолдеры или процессы;
* Спецификация — уточнение спецификации для устранения неопределенности, двусмысленности, несогласованности, повышения понимания (это как раз можно отнести к дефектам требований);
* Техническое решение — изменения, отражающие технические ограничения, принципиально новый дизайн или элегантность решения.
К внутренним причинам можно отнести только спецификацию — остальное меняется из-за внешних факторов.
В статье рассмотрен один проект из британского госсектора, стоимостью более миллиона фунтов (45-50 млн. руб по курсу 2010 г.), выполненный по водопадному подходу (был конкурс и внешний подрядчик) и длившийся примерно полтора года — в общем, похоже на довольно типовой проект.
Всего в требования было внесено 282 изменения: 67 на этапе сбора, 97 — при проектировании и разработке, 9 на этапе системного тестирования и 109 на этапе приемки пользователями.
По источникам на разных этапах они распределились так:
— этап требований: 30 — организация; 22 — спецификация; 15 — концепция.
— этап разработки: 58 — спецификация; 33 — решение; 4 — организация; по 1 — концепция и рынок.
— этап системного тестирования: 5 — спецификация; 3 — решение; 1 — концепция.
— этап приемки пользователями: 102 — спецификация; 7 — концепция.
В сумме, для 187 изменений из 282 источником была сама спецификация — её уточняли, дополняли и детализировали. На втором и третьем месте с небольшим разрывом между собой, но с огромным отставанием от спецификации — решение (36) и организация (34).
Так как это внутренний проект для одной организации, рынок тут практически не стал источником изменений (и в дальнейшем его не анализировали).
Дальше интереснее — нам важно не количество изменений, а их влияние на перерасход бюджета проекта, причем бюджета в человеко-днях. Ведь в деньгах можно намерять много чего (часто при измерении в деньгах сбиваются со стоимости исправления на стоимость последствий), а потраченные дополнительные человеко-дни — более объективная характеристика.
Стоимость задержки по источникам изменений и этапам, по убыванию:
1. Изменения спецификации на этапе приемки пользователями: 737 дней(!)
2. Изменения организации на этапе требований: 638 дней
3. Изменения концепции на этапе требований: 266 дней
4. Спецификация на этапе разработки: 222
5. Спецификация на этапе требований: 194
6. Концепция(!) на этапе приемки пользователями: 163 (!)
+ по мелочи
Изменения распределились в форме ванны: 46% (1097 человеко-дней) на этапе работы с требованиями и 38% (900 человеко-дней) — на этапе приемки.
Делаем вывод: отложенный фидбэк — путь к запланированным переделкам.
Изменение требований на этапе сбора требований — нормальный рабочий процесс, а вот на приемке этого хотелось бы избежать.
Но самое интересное — удельный вес изменений в зависимости от источника. Да, косяков в спецификации больше всего. Но в основном они мелкие: медианное значение — 4 дня. А вот одно изменение концепции на этапе приемки "стоит" 20 дней! Ещё дороже — изменения организации на этапе требований.
В общем, есть выбор — смерть от нескольких радикальных изменений концепции на последней стадии, или "смерть от тысячи порезов": мелких багов спеки. Это значит, что есть потенциал для улучшения — можно сэкономить целых 31%! Не сотни раз, но тоже немало.
👍27❤6
Меня иногда спрашивают — откуда я беру темы и как ищу неожиданные ракурсы. В основном из смежных областей. Всегда бывает интересно послушать, какие нашли решения похожих проблем в других индустриях.
Вот, например, медиа. Я вообще каким-то образом несколько лет учил журналистов использованию мультимедиа, применению ИТ-технологий и программированию, такой интересный был опыт. И я продолжаю читать некоторых титанов в этой области. Один из них — Александр Амзин — медиаконсультант и интернет-журналист (один из первых в России). Вроде бы пишет про медиа, а получается про управление продуктом, про подход к делам и вообще про жизнь.
Недавно ему исполнилось 45, и он опубликовал 45 пунктов: что понял за это время. И знаете, что? Почти под всеми я готов подписаться. Поэтому хочу поделиться этим списком с вами. Там есть многое, что применимо — ой, как применимо! — к разработке информационных систем.
Вот смотрите:
1. Самое интересное в жизни — решать задачки. Особенно те, которые еще никто не решил. Или которые ты сам придумал. Или которые считаются нерешаемыми.
2. Иногда единственный способ решить задачу — это усесться на задницу и сделать много скучных рутинных операций.
3. «Лучше день потерять, зато потом за пять минут долететь». Не лучше. Поиск оптимального варианта может занять в разы больше времени, чем сама работа. При этом никто не гарантирует, что поиск увенчается успехом.
4. Если тебе предлагают на выбор два варианта, не надо торопиться. В большинстве случаев можно отказаться от обоих. Или найти другие. Или выбрать сразу оба.
5. Вообще, если тебе говорят, что есть вот такая цель, но, к сожалению, действует некоторое ограничение, первый вопрос, который надо задать себе: «А можно ли избавиться от ограничения?» А второй вопрос: «Как на него повлиять и почему мы вообще его считаем неустранимым?» В подавляющем большинстве случаев ничего не получится, но иногда получается и это очень круто.
6. Один, определенный, ответ бывает только у очень простых вопросов. В жизни почти всегда работает комбинация факторов. Подобрать комбинацию до конца почти невозможно, но можно выделить 3-4 главных фактора и отбросить остальное.
[...]
8. Автоматизация переоценена. Если у тебя много данных на входе, тебе надо выработать внутреннее ощущение того, как все работает. Ручная работа создает опыт. Автоматизация — нет. Это не значит, что она не нужна. Но вглядываться в непредсказуемую бездну лучше своими глазами, иначе рискуешь что-то упустить.
[...]
13. «Лосось — стремительный, сильный и неутомимый. Он проплывает тысячи километров. Покоряет пороги и течения. Бороздит отмели и запрыгивает на водопады. Без сна. Без отдыха. В постоянном сражении со стихией. Он преодолевает все преграды, откладывает икру и, совершенно изможденный, дохнет. Так вот, запомни. Ты не лосось.»
14. Кстати, о лососях. Если продвигаться понемногу, но каждый день, ты гарантированно обгонишь всех, кто лососит по 16 часов в сутки, а потом неделю восстанавливается.
15. Планка почти всегда очень низкая. Чтобы в какой-то области разбираться лучше 90% людей, достаточно пары месяцев внимания. Но эти месяцы надо без дураков отдать нужной области. В большинстве мест планка специально установлена очень низко. Например, в школе тебя никто не пытается завалить — она создана для того, чтобы все ее закончили.
16. Если ты постоянно самый умный парень в комнате — ты заходишь не в те комнаты. Это приятно, но бессмысленно.
17. Надо быть специалистом в своей области, с этим никто не спорит. Но специалисты обычно разделяют общие ограничения, устаревшие понятия или заблуждения. Надо обязательно искать в других сферах оптику, которая может помочь в твоей сфере.
18. У общих неразрешимых проблем ОЧЕНЬ ЧАСТО есть вполне вменяемые частные решения. Поэтому вопрос «Какую проблему решаем?» должен все время крутиться на языке.
Продолжение тут
Вот, например, медиа. Я вообще каким-то образом несколько лет учил журналистов использованию мультимедиа, применению ИТ-технологий и программированию, такой интересный был опыт. И я продолжаю читать некоторых титанов в этой области. Один из них — Александр Амзин — медиаконсультант и интернет-журналист (один из первых в России). Вроде бы пишет про медиа, а получается про управление продуктом, про подход к делам и вообще про жизнь.
Недавно ему исполнилось 45, и он опубликовал 45 пунктов: что понял за это время. И знаете, что? Почти под всеми я готов подписаться. Поэтому хочу поделиться этим списком с вами. Там есть многое, что применимо — ой, как применимо! — к разработке информационных систем.
Вот смотрите:
1. Самое интересное в жизни — решать задачки. Особенно те, которые еще никто не решил. Или которые ты сам придумал. Или которые считаются нерешаемыми.
2. Иногда единственный способ решить задачу — это усесться на задницу и сделать много скучных рутинных операций.
3. «Лучше день потерять, зато потом за пять минут долететь». Не лучше. Поиск оптимального варианта может занять в разы больше времени, чем сама работа. При этом никто не гарантирует, что поиск увенчается успехом.
4. Если тебе предлагают на выбор два варианта, не надо торопиться. В большинстве случаев можно отказаться от обоих. Или найти другие. Или выбрать сразу оба.
5. Вообще, если тебе говорят, что есть вот такая цель, но, к сожалению, действует некоторое ограничение, первый вопрос, который надо задать себе: «А можно ли избавиться от ограничения?» А второй вопрос: «Как на него повлиять и почему мы вообще его считаем неустранимым?» В подавляющем большинстве случаев ничего не получится, но иногда получается и это очень круто.
6. Один, определенный, ответ бывает только у очень простых вопросов. В жизни почти всегда работает комбинация факторов. Подобрать комбинацию до конца почти невозможно, но можно выделить 3-4 главных фактора и отбросить остальное.
[...]
8. Автоматизация переоценена. Если у тебя много данных на входе, тебе надо выработать внутреннее ощущение того, как все работает. Ручная работа создает опыт. Автоматизация — нет. Это не значит, что она не нужна. Но вглядываться в непредсказуемую бездну лучше своими глазами, иначе рискуешь что-то упустить.
[...]
13. «Лосось — стремительный, сильный и неутомимый. Он проплывает тысячи километров. Покоряет пороги и течения. Бороздит отмели и запрыгивает на водопады. Без сна. Без отдыха. В постоянном сражении со стихией. Он преодолевает все преграды, откладывает икру и, совершенно изможденный, дохнет. Так вот, запомни. Ты не лосось.»
14. Кстати, о лососях. Если продвигаться понемногу, но каждый день, ты гарантированно обгонишь всех, кто лососит по 16 часов в сутки, а потом неделю восстанавливается.
15. Планка почти всегда очень низкая. Чтобы в какой-то области разбираться лучше 90% людей, достаточно пары месяцев внимания. Но эти месяцы надо без дураков отдать нужной области. В большинстве мест планка специально установлена очень низко. Например, в школе тебя никто не пытается завалить — она создана для того, чтобы все ее закончили.
16. Если ты постоянно самый умный парень в комнате — ты заходишь не в те комнаты. Это приятно, но бессмысленно.
17. Надо быть специалистом в своей области, с этим никто не спорит. Но специалисты обычно разделяют общие ограничения, устаревшие понятия или заблуждения. Надо обязательно искать в других сферах оптику, которая может помочь в твоей сфере.
18. У общих неразрешимых проблем ОЧЕНЬ ЧАСТО есть вполне вменяемые частные решения. Поэтому вопрос «Какую проблему решаем?» должен все время крутиться на языке.
Продолжение тут
👍26❤13🔥6💯2👏1
Помните карту с 162 атрибутами качества программных систем? У нас для качества требований столько не наберется, но вот ученые в эмпирических исследованиях обнаружили 111 (не знаю, как они считали, у меня получилось 89, но всё равно впечатляет!)
Это не все атрибуты, это те, что исследовали эмпирически. У нас ведь с эмпирическими данными есть некоторая проблема — как мы знаем, многие выводы и модели разработки не основаны примерно ни на чем, кроме интересных мыслей их авторов. Но это так много где — в психологии даже исследования есть, но мало какие их них воспроизводятся.
Так вот, с 1996 года нормальных исследований требований всего-то нашлось 105 (остальные либо не эмпирические, либо из них не удалось извлечь данные). Что и как исследуют тоже интересно.
Больше всего, как видно, ученых интересует недвусмысленность и полнота (ну или завершенность). На третьем месте — консистентность (или по-русски "соответствие"). С точки зрения цели исследования — улучшение этой самой полноты, недвусмысленности и конститентности. Другие варианты — оценка и попытка дать определение, но таких исследований крайне мало.
Получается любопытная картина — пытаемся улучшать то, чему толком не можем дать определения (например, свойству "недвусмысленности").
Также интересно, что участники исследований очень часто выступают не как субъекты, которых исследуют, а как источники оценки в отношении требований. То есть и оценка у нас не очень-то формальна.
Дальше больше — в половине исследований использовался эксперимент, и, вообще говоря, нет данных о переносимости результатов в индустриальную практику. (Из 105 исследований только 18 проверены в индустрии). Для науки интересно, а как оно в реальности работает...
Мало того — в 67% исследований ученые вообще не особо разбирались, в каком виде записаны требования. Ну просто требования и требования, без уточнений, что там — юскейсы или джоб сторис, или ещё что-то.
Несмотря на это, считаю, что картинка очень интересна для разглядывания, и имеет практическое применения. Я сам довольно давно агитирую всех обращать пристальное внимание на язык и тексты требований, а теперь это стало вдвойне актуально с появлением ИИ. С одной стороны, он может проверить то, что раньше человеку было не под силу — ну как вы проверите 89 критериев требований?
С другой, его самого теперь нужно проверять, а учился он не на лучших образцах, а на тех, что есть. Поэтому все эти ошибки ему так же свойственны. Так что карта просится в промпт, осталось только операционализировать каждое свойство. А пока можно просто поразглядывать красивую картнику на выходных.
Источник всего этого богатства — систематический анализ литературы на тему качества требований 2022 года.
Перевод мой авторский, замечания принимаются.
График построен в https://www.rawgraphs.io/
Это не все атрибуты, это те, что исследовали эмпирически. У нас ведь с эмпирическими данными есть некоторая проблема — как мы знаем, многие выводы и модели разработки не основаны примерно ни на чем, кроме интересных мыслей их авторов. Но это так много где — в психологии даже исследования есть, но мало какие их них воспроизводятся.
Так вот, с 1996 года нормальных исследований требований всего-то нашлось 105 (остальные либо не эмпирические, либо из них не удалось извлечь данные). Что и как исследуют тоже интересно.
Больше всего, как видно, ученых интересует недвусмысленность и полнота (ну или завершенность). На третьем месте — консистентность (или по-русски "соответствие"). С точки зрения цели исследования — улучшение этой самой полноты, недвусмысленности и конститентности. Другие варианты — оценка и попытка дать определение, но таких исследований крайне мало.
Получается любопытная картина — пытаемся улучшать то, чему толком не можем дать определения (например, свойству "недвусмысленности").
Также интересно, что участники исследований очень часто выступают не как субъекты, которых исследуют, а как источники оценки в отношении требований. То есть и оценка у нас не очень-то формальна.
Дальше больше — в половине исследований использовался эксперимент, и, вообще говоря, нет данных о переносимости результатов в индустриальную практику. (Из 105 исследований только 18 проверены в индустрии). Для науки интересно, а как оно в реальности работает...
Мало того — в 67% исследований ученые вообще не особо разбирались, в каком виде записаны требования. Ну просто требования и требования, без уточнений, что там — юскейсы или джоб сторис, или ещё что-то.
Несмотря на это, считаю, что картинка очень интересна для разглядывания, и имеет практическое применения. Я сам довольно давно агитирую всех обращать пристальное внимание на язык и тексты требований, а теперь это стало вдвойне актуально с появлением ИИ. С одной стороны, он может проверить то, что раньше человеку было не под силу — ну как вы проверите 89 критериев требований?
С другой, его самого теперь нужно проверять, а учился он не на лучших образцах, а на тех, что есть. Поэтому все эти ошибки ему так же свойственны. Так что карта просится в промпт, осталось только операционализировать каждое свойство. А пока можно просто поразглядывать красивую картнику на выходных.
Источник всего этого богатства — систематический анализ литературы на тему качества требований 2022 года.
Перевод мой авторский, замечания принимаются.
График построен в https://www.rawgraphs.io/
1🔥14👍4👏2❤1
Залез в mermaid.js по какой-то надобности, а он теперь mermaid.ai, весь такой ИИ-интегрированный.
Пишешь ему промпт, он по нему строит диаграмму, причем не сразу, а сначала ещё вопросы задает. Правда, в бесплатном режиме доступны только 15 кредитов (1 кредит = 1 запрос к ИИ), так что с этими переспрашиваниями сгорают они моментально.
Вообще интересно, как продукт развивается (в отличие от застывшего PlantUML). Там теперь кроме UML и диаграмм архитектуры есть базовые графики, любимые консалтерские квадранты, диаграмма Ганта, даже sankey и radar chart есть. Можно прямо не выходя из инструмента сделать презентацию — такой режим тоже есть (правда, в бесплатной версии дается только три диаграммы, не разгуляешься).
Ну и это продукт на основе open source библиотеки — идеальный пример, как по мне.
Впрочем, я про другое хотел написать — там же ИИ дает подсказки, и в одну из них я не удержался, тыкнул. Потому что это алгоритм обновления версии API. Интересно было посмотреть, что там предлагается.
Ну, в общем, ничего сверхъестественного, просто аккуратный алгоритм. Что важно — половина от него — это план коммуникаций. Не технические вещи, которые тут тоже упущены и по которым должно быть приняты решения (например, как конкретно мы поддерживаем две версии API как устроен код контроллеров? Что с БД делаем, особенно если добавились обязательные поля, которых не было в старой версии?..)
Я бы сказал, что в плане коммуникаций тут не хватает ещё взаимодействия с поддержкой — чтобы знали, как и что отвечать по поводу сроков вывода и нюансов работы API.
И вот что интересно — а какая роль за этот план отвечает? За его разработку, имплементацию и поддержку в актуальном состоянии? Помнится, в одном из проектов лет 10 назад мы пытались нанять человека, который бы взял на себя развитие открытых API, привлечение разработчиков и развитие технологических партнерств, но не только не смогли найти, но даже не поняли, как эта роль должна называться — API Product Manager? Head of API Strategy & Partnership? External Developers Advocate?
В итоге, как обычно, это упало куда-то между аналитиком, продактом и маркетингом, и там благополучно умерло.
А у вас есть такие люди, которые целенаправленно занимаются развитием внешнего API и коммуникацией по этому поводу? Как называются?
Пишешь ему промпт, он по нему строит диаграмму, причем не сразу, а сначала ещё вопросы задает. Правда, в бесплатном режиме доступны только 15 кредитов (1 кредит = 1 запрос к ИИ), так что с этими переспрашиваниями сгорают они моментально.
Вообще интересно, как продукт развивается (в отличие от застывшего PlantUML). Там теперь кроме UML и диаграмм архитектуры есть базовые графики, любимые консалтерские квадранты, диаграмма Ганта, даже sankey и radar chart есть. Можно прямо не выходя из инструмента сделать презентацию — такой режим тоже есть (правда, в бесплатной версии дается только три диаграммы, не разгуляешься).
Ну и это продукт на основе open source библиотеки — идеальный пример, как по мне.
Впрочем, я про другое хотел написать — там же ИИ дает подсказки, и в одну из них я не удержался, тыкнул. Потому что это алгоритм обновления версии API. Интересно было посмотреть, что там предлагается.
Ну, в общем, ничего сверхъестественного, просто аккуратный алгоритм. Что важно — половина от него — это план коммуникаций. Не технические вещи, которые тут тоже упущены и по которым должно быть приняты решения (например, как конкретно мы поддерживаем две версии API как устроен код контроллеров? Что с БД делаем, особенно если добавились обязательные поля, которых не было в старой версии?..)
Я бы сказал, что в плане коммуникаций тут не хватает ещё взаимодействия с поддержкой — чтобы знали, как и что отвечать по поводу сроков вывода и нюансов работы API.
И вот что интересно — а какая роль за этот план отвечает? За его разработку, имплементацию и поддержку в актуальном состоянии? Помнится, в одном из проектов лет 10 назад мы пытались нанять человека, который бы взял на себя развитие открытых API, привлечение разработчиков и развитие технологических партнерств, но не только не смогли найти, но даже не поняли, как эта роль должна называться — API Product Manager? Head of API Strategy & Partnership? External Developers Advocate?
В итоге, как обычно, это упало куда-то между аналитиком, продактом и маркетингом, и там благополучно умерло.
А у вас есть такие люди, которые целенаправленно занимаются развитием внешнего API и коммуникацией по этому поводу? Как называются?
1🔥7❤6👍1