не на уровне должностной инструкции, а такое, которое физически не пустит в работу задачу без определения сценария приемочного теста, если этот тест не прошел ревью, если всё, что связано с постановкой не преодолело связанный с этим Quality Gate, в котором установлены некие конкретные критерии, то про это решение было бы очень интересно узнать. У нас, как-то так получается, что любые заходы к аналитикам заканчиваются на уровне "а, так это че-т делать надо, в чем-то разбираться? не, идея классная, но у нас сейчас другое совещание начнется, давайте завтра. Или лучше знаете что, лучше никогда!"
это очень хороший вопрос) Потому что на одном из проектов выделили целую команду, которая описывала процессы в конфлюенс. Процессы были классными, читались на одном дыхании. Одна только проблема: никто эти процессы не внедрял)
Ответ же есть: "BDD являются предпосылки, при которых этот подход работает. Иначе получится лишь имитация подхода". Вы пишете, что аналитики не хотят. Совещания и т.п. Ответ очевиден - если очень хочется внедрить BDD придется поменять аналитиков. Либо обучить, либо физически поменять. Более того, ни на одном из проектов в объемах всего проекта не удалось внедрить BDD. Получилось сделать только в паре команд разработки. Но возможно, я что-то делал не так)
В половине проектов, я видел консультантов и в стадии разработки на должности типа Program Architect и даже на стадии первичных UAT. Big4 стараются гарантировать обоснованность своей работы (они очень дорого берут за свое имя и потому сильно дорожат им) и доказать свою незаменимость (как раз основываясь на решениях клиента "вопреки" и на факте изменения требований с течением времени). Им очень выгодно нести эту ответственность, так как на самом деле они играют в стрелки, обосновывая проблемы либо решениями заказчика, либо ошибками разработчика (а там часто ещё и обслуживанием занимается кто-то третий). Проект то явно на год (-ы) разработки и любой аудитор захочет сидеть и назначать виноватых за большие деньги в течении всего этого срока.
тут похоже мы сходимся во мнениях. Подход, когда консультантом при формировании требований и аудитором на стадии реализации является одно и то же юр-лицо, по-моему влечет конфликт интересов. Эту мысль пытался донести.
Отлично, только у нас не ватерфол, так что проработанных требований всё равно не будет, а если вы уже согласились (подписали), то уповать вам стоит только на адекватность заказчика. Обычно все понимают правила игры, но в случае форс мажора (допустим смена руководителей или промах по бюджету и срокам), вполне могут вспомнить формальности.
не waterfall на каком уровне? На уровне программы проектов как раз waterfall. Сначала проект Консультанта, потом конкурс, потом реализация. И даже на уровне проекта по разработке случается видеть waterfall, когда привязывают платежи к этапам, как в проектах внедрения готовых приложений. Вопрос же не в том, что требования не могут меняться и уточняться. А в том, что требования на входе были некачественные и неполные и при этом достаточно сложно требования поменять, уточнить по причинам, описанным в статье.
Обычно все стороны хороши. И сейлзы со стороны разработчика (ваши) вписывают вас в проект не глядя, чтоб получить свои лёгкие деньги. Никогда не видел, чтоб бонус они получали по факту сдачи проекта клиенту. Только серьёзные убытки заставили одну компанию включить архитектора в пресейл, чтоб он мог делать ту самую валидацию требований, до подписания и взятых обязательств
здесь двух мнений быть не может) Конечно, на этапе продажи можно было бы подложить соломки. На самом деле архитекторы были всегда на пресейле. Даже выполнялись тестовые задания. Вопрос: почему договор оказывается невыполнимым с т.з. требований и управления изменениями - очевидно можно адресовать к команде продаж.
это очень хороший вопрос) Потому что на одном из проектов выделили целую команду, которая описывала процессы в конфлюенс. Процессы были классными, читались на одном дыхании. Одна только проблема: никто эти процессы не внедрял)
Ответ же есть: "BDD являются предпосылки, при которых этот подход работает. Иначе получится лишь имитация подхода". Вы пишете, что аналитики не хотят. Совещания и т.п. Ответ очевиден - если очень хочется внедрить BDD придется поменять аналитиков. Либо обучить, либо физически поменять. Более того, ни на одном из проектов в объемах всего проекта не удалось внедрить BDD. Получилось сделать только в паре команд разработки. Но возможно, я что-то делал не так)
Спасибо за комментарии по первому разделу)
тут похоже мы сходимся во мнениях. Подход, когда консультантом при формировании требований и аудитором на стадии реализации является одно и то же юр-лицо, по-моему влечет конфликт интересов. Эту мысль пытался донести.
не waterfall на каком уровне? На уровне программы проектов как раз waterfall. Сначала проект Консультанта, потом конкурс, потом реализация. И даже на уровне проекта по разработке случается видеть waterfall, когда привязывают платежи к этапам, как в проектах внедрения готовых приложений. Вопрос же не в том, что требования не могут меняться и уточняться. А в том, что требования на входе были некачественные и неполные и при этом достаточно сложно требования поменять, уточнить по причинам, описанным в статье.
здесь двух мнений быть не может) Конечно, на этапе продажи можно было бы подложить соломки. На самом деле архитекторы были всегда на пресейле. Даже выполнялись тестовые задания. Вопрос: почему договор оказывается невыполнимым с т.з. требований и управления изменениями - очевидно можно адресовать к команде продаж.