Здравствуйте, SkyDance, Вы писали:

N>>Я бы согласился. Но я видел проекты, которые запутаны как раз обезьянами до такой степени, что чтобы с ними что-то полезное сделать, надо вначале их распутать. А это таки проблема.

SD>Это не проблема, а action item.

action item оно становится, когда его согласны принять в работу.

N>>Поэтому я предпочту хотя бы частично, но ту самую "чистую архитектуру" таки начать реализовывать. Всегда полезно иметь экономию в несколько недель или месяцев вхождения в тематику...

SD>Вот видишь, это вполне конкретный сценарий. У него есть ничуть не менее конкретный business value — "несколько месяцев вхождения". И это не нечто абстрактное, типа "upfront architecture", которая может понадобиться через год, а — что-то несущее пользу прямо сейчас. Причем я уверен, что разработчики будут в состоянии оценить, сколько труда (Story Points) требуется для создания определенного набора документации.
SD>Это вполне укладывается в Scrum. И почему-то мне кажется, что сие не будет монолитной задачей на 3 спринта всей команды, а будет состоять из очень даже небольших в объеме stories, типа "описать как мы хотели чтобы работала эта фича", "описать общую архитектуру" и т.п.. Такие задачи чаще всего бывают в районе 2-8 SP (напоминаю, 1 SP — это минимальная задача по DoD).

Ты вот про "значительный опыт" рассказываешь, а читаешь у собеседника что-то совсем не то, что он писал прямым текстом.
Ещё раз: "чистая архитектура" предназначается для того, чтобы как раз не попадать в ситуацию с высоким порогом вхождения и с необходимостью распутывания перед тем, как начать делать реально что-то полезное.
Насколько оно будет при этом соответствовать той конкретной "чистой архитектуре", которая у Мартина или кто там сейчас дежурный пророк — вопрос уже чуть более второстепенный.
А где ты нашёл какие-то "сценарии" — мне в упор непонятно. Они будут появляться только если таки запустить проблему и позволить коду деградировать (или явно заранее намешать, как один предшественник).

Здравствуйте, SkyDance, Вы писали:

N>>Я бы согласился. Но я видел проекты, которые запутаны как раз обезьянами до такой степени, что чтобы с ними что-то полезное сделать, надо вначале их распутать. А это таки проблема.

SD>Это не проблема, а action item.

action item оно становится, когда его согласны принять в работу. Или в твоём диалекте это что-то другое?

N>>Поэтому я предпочту хотя бы частично, но ту самую "чистую архитектуру" таки начать реализовывать. Всегда полезно иметь экономию в несколько недель или месяцев вхождения в тематику...

SD>Вот видишь, это вполне конкретный сценарий. У него есть ничуть не менее конкретный business value — "несколько месяцев вхождения". И это не нечто абстрактное, типа "upfront architecture", которая может понадобиться через год, а — что-то несущее пользу прямо сейчас. Причем я уверен, что разработчики будут в состоянии оценить, сколько труда (Story Points) требуется для создания определенного набора документации.
SD>Это вполне укладывается в Scrum. И почему-то мне кажется, что сие не будет монолитной задачей на 3 спринта всей команды, а будет состоять из очень даже небольших в объеме stories, типа "описать как мы хотели чтобы работала эта фича", "описать общую архитектуру" и т.п.. Такие задачи чаще всего бывают в районе 2-8 SP (напоминаю, 1 SP — это минимальная задача по DoD).

Ты вот про "значительный опыт" рассказываешь, а читаешь у собеседника что-то совсем не то, что он писал прямым текстом.
Ещё раз: "чистая архитектура" предназначается для того, чтобы как раз не попадать в ситуацию с высоким порогом вхождения и с необходимостью распутывания перед тем, как начать делать реально что-то полезное.
Насколько оно будет при этом соответствовать той конкретной "чистой архитектуре", которая у Мартина или кто там сейчас дежурный пророк — вопрос уже чуть более второстепенный.
А где ты нашёл какие-то "сценарии" — мне в упор непонятно. Они будут появляться только если таки запустить проблему и позволить коду деградировать (или явно заранее намешать, как один предшественник).

Как вы режете у себя на storypoints — это ваше дело. Но я вместе со многими другими предпочитаю таки считать в единицах рабочего времени среднего участника, и не связывать с "минимальными задачами по DoD" или какими-то ещё сферическими попугаями в условном вакууме.