Не соглашусь только про камеру - по моему опыту, это может сильно отвлекать как ведущих, так и слушателей. Бывают ещё и проблемы с трафиком из-за видео. Но команде виднее
В целом, встреча (созвон) - это ровно такой же рабочий процесс, как и все остальные, содержит все те же самые составляющие (проблема/задача, цель, результат, ресурсы компетенции & исполнения & контроля, входящие/исходящие артефакты...). Поэтому, если ко встрече подходить как к проектированию рабочего процесса, то результат процесса будет качественнее.
Насколько понимаю, невозможно заранее утверждать, что встреча достигнет полного результата. Требуемые ресурсы компетенции для принятия решений могут стать полностью известны только в процессе встречи. Тут только знания, опыт и прочий профессионализм уменьшает степень риска
В самом начале. Непонятно, откуда родились НФТ. Про ФТ всё честно: БТ-ФТ. Вероятно, должно быть (БТ+ФТ)-НФТ
Там же. ФТ-ТК (тест-кейсы). Логичнее (ФТ+UC)-ТК. Потому как ТК это, фактически, UC с результатом из ФТ
функционал реализован, но не соответствует бизнес-требованиям
Всё-таки, "функциональность" звучит приятнее для слуха профессионала :) Главное, тут непонятно, откуда тогда взялась функциональность (мы же всё страссировали при проектировании, верно?). Тут что-то не то или с мыслью, или с формулировкой.
Контроль полноты реализации требований. Позволяет убедиться, что каждое требование было учтено и реализовано в системе. Здесь можно использовать соответствие функциональных и бизнес-требований
Какое отношение имеет соответствие ФТ и БТ, и что использовано в разработке? Надо проверять через все цепочки БТ с результатом (тестами) разработки. ФТ тут промежуточные
Судя по вашей табличке, количество ядер на процессор, наоборот, упало примерно в 2.5 раза. И тактовая частота тоже. Это означает гораздо больше занимаемый объём этой махиной
Заявлено: "как за 8 часов исследовать продуктовый сценарий, нагенерить идей и взяться за макеты". Реально: всё есть, "Заказчик отметил моменты, которые надо доработать" на готовом превью, над которым целая команда работала 3 месяца.
Проблемы на входе? Неизвестны, поэтому зачем и почему всё дальше делает ТС - читатель должен сам догадаться. Я не догадался, ибо нет времени.
Результат? Много разноцветных разномастных элементов, стрелочек на трёх скринах. Я опять туплю, но времени вникать нет. Понятно сформулирована только нерешённая проблема
Крайне скептически отношусь к полезности корпоративных блогов, но этот пост очень содержателен. Правда, не всё нужное увидел (например, структуру доков для управления функциональными требованиями/описаниями). В целом очень здорово. Многие большие команды, которые видел, сильно не дотягивают до уровня этого поста.
Из личного. Год или два назад вакансии аналитиков в Спорт-Мастер запомнились как крайне скучные и формальные. Вероятно, что-то изменилось
О чём и речь. Вы сами зафиксировали, что все варианты оканчиваются одним остановом (завершением процесса) - так соблюдайте же это. Вы понимаете, что один останов и три останова - это, соответственно, одна и три независимые сущности в системе? Вам проще контролировать одну точку или три? Что за содержание между ветвлением и окончанием этого ветвления - вообще не важно, артефакт или суперсложный подпроцесс. Но если вы сейчас, как нарисовали, отпустите на волю этот подпроцес, вы легко и непринуждённо вернётесь назад (плодя логические петли), совершенно забыв про обязательное условие - зафиксировать результат ветвления в собирающем шлюзе.
В реальных системах мы обязаны соблюдать формальную логику, а не "и так же очевидно, чё тут усложнять". Потому что она не для красоты, а для контроля (человеком или движком) начала и завершения всей модели. Поэтому такие примеры, на мой взгляд, вредны.
Тут другие читатели верно заметили про первый пример, где так легко и непринуждённо упущен собирающий шлюз. Это нарушение логики, потенциально ведущее к потерю контроля за процессом.
Решается просто. Что общее у вариантов? Завершение - значит, его оставляем. Собирающий шлюз для соблюдения формальной логики. А что надо, чтобы показать то, что хочет автор? Просто зафиксировть результат процесса, например, доком (артефактом) в каждом варианте. Это гораздо правильнее, потому что в реальной системе комменты на схеме останутся комментами, а артефакт на схеме - это реальный запись в системе с результатом процесса
Сопротивление резистора R2 выше, чем R1, а это ограничивает возможность тока потечь через него
Если дословно верить фразе, то автору удалось придумать альтернативный закон Киргофа - от сопротивлений теперь зависит не сила тока, а его вероятность (возможность). А всего-то не надо вставлять слова-паразиты в технический текст.
Да, спасибо, понял вашу модель мира разработки. Резюме
Бизнес и разработка - это про проблемы и боль, а не про достижения новых целей. Только уменьшение или устранение этой боли. Команда разработки - это спасатели и врачеватели.
Сначала где-то в голове декомпозируем задачу проблему до разработки, на этапе разработки спохватываемся и начинаем обратную композицию, не потеряли ли что по дороге (ведь артефактов декомпозиции нет, потому что на этапе разработки "уже забывается", верно? Если бы они были, то при обязательной валидации каждого последующего шага декомпозиции обратная цепочка говорит лишь об профессиональном провале всех уровней анализа проекта)
По рис.2. Системы решают только проблемы? Просто задачи бизнеса они не решают?
Рис.4 противоречит содержанию всей статьи. Движение от разработки к решению задач бизнеса - как такое возможно? Собираются, значит, разрабы и давай разворачивать программные компоненты чтобы... и постепенно так рождаются задачи бизнеса. Прямо пластилиновый мультик
Когда-то давно тратил часы для бытовых задач (сложные групповые переименования), чтобы разобраться в этом адовом скпоплении символов. Как правило, безуспешно. И какая прекрасная эра наступила сейчас! Формулирую ИИ, вставляю какой-тоужасныйнаборнепонятночего в нужную программку - и всё, программка выдаёт нужный результат.
Если что, я, конечно, реально преклоняюсь перед теми, кто в этом как в воде. Но это надо иметь очень продвинутый мозг...
У домена нет ограниченного контекста - значит, что или домен не имеет контекста, или контекст не ограничен. В 1-м случае домен перестаёт существовать, т.к. ничего не содержит. Отметаем. Во 2-м случае мы можем напихать в контекст что угодно. В приведённом примере можно добавить, что компания занимается майнингом и торговлей криптовалюты для обеспечения закупок и взаиморасчётов. Теперь ваш домен включает приличный кусок деятельности, обеспечение которой может затмить (заменить, угробить) поставленную цель.
Так есть у домена свой ограниченный контекст или нет? Пока не понимаю, почему ограниченный контекст внезапно появляется только в поддоменах
Тут я приготовился увидеть резюме статьи для лентяев типа меня. И... вижу какие-то общие слова и какое-то изречение для камня. Т.е. вся статья, с уймой технических подробностей и типа смешными картинками, была написана, чтобы в финале дать наставления читающим?!
Не соглашусь только про камеру - по моему опыту, это может сильно отвлекать как ведущих, так и слушателей. Бывают ещё и проблемы с трафиком из-за видео.
Но команде виднее
В целом, встреча (созвон) - это ровно такой же рабочий процесс, как и все остальные, содержит все те же самые составляющие (проблема/задача, цель, результат, ресурсы компетенции & исполнения & контроля, входящие/исходящие артефакты...). Поэтому, если ко встрече подходить как к проектированию рабочего процесса, то результат процесса будет качественнее.
Насколько понимаю, невозможно заранее утверждать, что встреча достигнет полного результата. Требуемые ресурсы компетенции для принятия решений могут стать полностью известны только в процессе встречи. Тут только знания, опыт и прочий профессионализм уменьшает степень риска
В самом начале. Непонятно, откуда родились НФТ. Про ФТ всё честно: БТ-ФТ.
Вероятно, должно быть (БТ+ФТ)-НФТ
Там же. ФТ-ТК (тест-кейсы). Логичнее (ФТ+UC)-ТК. Потому как ТК это, фактически, UC с результатом из ФТ
Всё-таки, "функциональность" звучит приятнее для слуха профессионала :)
Главное, тут непонятно, откуда тогда взялась функциональность (мы же всё страссировали при проектировании, верно?). Тут что-то не то или с мыслью, или с формулировкой.
Какое отношение имеет соответствие ФТ и БТ, и что использовано в разработке? Надо проверять через все цепочки БТ с результатом (тестами) разработки. ФТ тут промежуточные
Ну там много чего дальше, нет времени, ссори
del
Попробуйте прочитать не только заголовок
Перевод кривой. Динамик не может быть ни BT, ни WiFi, не может иметь аккумулятор и т.п. А вот колонка (акустическая система) - может
Судя по вашей табличке, количество ядер на процессор, наоборот, упало примерно в 2.5 раза. И тактовая частота тоже. Это означает гораздо больше занимаемый объём этой махиной
Заявлено: "как за 8 часов исследовать продуктовый сценарий, нагенерить идей и взяться за макеты".
Реально: всё есть, "Заказчик отметил моменты, которые надо доработать" на готовом превью, над которым целая команда работала 3 месяца.
Проблемы на входе? Неизвестны, поэтому зачем и почему всё дальше делает ТС - читатель должен сам догадаться.
Я не догадался, ибо нет времени.
Результат? Много разноцветных разномастных элементов, стрелочек на трёх скринах.
Я опять туплю, но времени вникать нет. Понятно сформулирована только нерешённая проблема
Увидел
и на этом закончил.
Представляю, какая там каша дальше возможна, если сразу на взлёте чел базово не понимает про объектность/субъектность
Крайне скептически отношусь к полезности корпоративных блогов, но этот пост очень содержателен. Правда, не всё нужное увидел (например, структуру доков для управления функциональными требованиями/описаниями). В целом очень здорово. Многие большие команды, которые видел, сильно не дотягивают до уровня этого поста.
Из личного. Год или два назад вакансии аналитиков в Спорт-Мастер запомнились как крайне скучные и формальные. Вероятно, что-то изменилось
О чём и речь.
Вы сами зафиксировали, что все варианты оканчиваются одним остановом (завершением процесса) - так соблюдайте же это. Вы понимаете, что один останов и три останова - это, соответственно, одна и три независимые сущности в системе? Вам проще контролировать одну точку или три?
Что за содержание между ветвлением и окончанием этого ветвления - вообще не важно, артефакт или суперсложный подпроцесс. Но если вы сейчас, как нарисовали, отпустите на волю этот подпроцес, вы легко и непринуждённо вернётесь назад (плодя логические петли), совершенно забыв про обязательное условие - зафиксировать результат ветвления в собирающем шлюзе.
В реальных системах мы обязаны соблюдать формальную логику, а не "и так же очевидно, чё тут усложнять". Потому что она не для красоты, а для контроля (человеком или движком) начала и завершения всей модели. Поэтому такие примеры, на мой взгляд, вредны.
Тут другие читатели верно заметили про первый пример, где так легко и непринуждённо упущен собирающий шлюз. Это нарушение логики, потенциально ведущее к потерю контроля за процессом.
Решается просто.
Что общее у вариантов? Завершение - значит, его оставляем. Собирающий шлюз для соблюдения формальной логики. А что надо, чтобы показать то, что хочет автор? Просто зафиксировть результат процесса, например, доком (артефактом) в каждом варианте.
Это гораздо правильнее, потому что в реальной системе комменты на схеме останутся комментами, а артефакт на схеме - это реальный запись в системе с результатом процесса
Заголовки 3 и 4 (US и UC) перепутаны местами
Добавлю:
Если дословно верить фразе, то автору удалось придумать альтернативный закон Киргофа - от сопротивлений теперь зависит не сила тока, а его вероятность (возможность).
А всего-то не надо вставлять слова-паразиты в технический текст.
Вижу маленькую коробочку (слайд 2) с офигительной вычислительной мощностью и полным отсутствием принудительной вентиляции. Очень интересно
А мне немного странно, что вместо ответа по существу лезем в профиль человека и начинаем его обсуждать. Очень топорное поведение
Да, спасибо, понял вашу модель мира разработки. Резюме
Бизнес и разработка - это про проблемы и боль, а не про достижения новых целей. Только уменьшение или устранение этой боли. Команда разработки - это спасатели и врачеватели.
Сначала где-то в голове декомпозируем
задачупроблему до разработки, на этапе разработки спохватываемся и начинаем обратную композицию, не потеряли ли что по дороге (ведь артефактов декомпозиции нет, потому что на этапе разработки "уже забывается", верно? Если бы они были, то при обязательной валидации каждого последующего шага декомпозиции обратная цепочка говорит лишь об профессиональном провале всех уровней анализа проекта)По рис.2. Системы решают только проблемы? Просто задачи бизнеса они не решают?
Рис.4 противоречит содержанию всей статьи. Движение от разработки к решению задач бизнеса - как такое возможно?
Собираются, значит, разрабы и давай разворачивать программные компоненты чтобы... и постепенно так рождаются задачи бизнеса. Прямо пластилиновый мультик
Когда-то давно тратил часы для бытовых задач (сложные групповые переименования), чтобы разобраться в этом адовом скпоплении символов. Как правило, безуспешно. И какая прекрасная эра наступила сейчас! Формулирую ИИ, вставляю какой-тоужасныйнаборнепонятночего в нужную программку - и всё, программка выдаёт нужный результат.
Если что, я, конечно, реально преклоняюсь перед теми, кто в этом как в воде. Но это надо иметь очень продвинутый мозг...
У домена нет ограниченного контекста - значит, что или домен не имеет контекста, или контекст не ограничен.
В 1-м случае домен перестаёт существовать, т.к. ничего не содержит. Отметаем.
Во 2-м случае мы можем напихать в контекст что угодно. В приведённом примере можно добавить, что компания занимается майнингом и торговлей криптовалюты для обеспечения закупок и взаиморасчётов. Теперь ваш домен включает приличный кусок деятельности, обеспечение которой может затмить (заменить, угробить) поставленную цель.
Так есть у домена свой ограниченный контекст или нет?
Пока не понимаю, почему ограниченный контекст внезапно появляется только в поддоменах
Тут я приготовился увидеть резюме статьи для лентяев типа меня. И... вижу какие-то общие слова и какое-то изречение для камня.
Т.е. вся статья, с уймой технических подробностей и типа смешными картинками, была написана, чтобы в финале дать наставления читающим?!