N>Я бы согласился. Но я видел проекты, которые запутаны как раз обезьянами до такой степени, что чтобы с ними что-то полезное сделать, надо вначале их распутать. А это таки проблема.
Это не проблема, а action item.
N>Поэтому я предпочту хотя бы частично, но ту самую "чистую архитектуру" таки начать реализовывать. Всегда полезно иметь экономию в несколько недель или месяцев вхождения в тематику...
Вот видишь, это вполне конкретный сценарий. У него есть ничуть не менее конкретный business value — "несколько месяцев вхождения". И это не нечто абстрактное, типа "upfront architecture", которая может понадобиться через год, а — что-то несущее пользу прямо сейчас. Причем я уверен, что разработчики будут в состоянии оценить, сколько труда (Story Points) требуется для создания определенного набора документации.
Это вполне укладывается в Scrum. И почему-то мне кажется, что сие не будет монолитной задачей на 3 спринта всей команды, а будет состоять из очень даже небольших в объеме stories, типа "описать как мы хотели чтобы работала эта фича", "описать общую архитектуру" и т.п.. Такие задачи чаще всего бывают в районе 2-8 SP (напоминаю, 1 SP — это минимальная задача по DoD).
KP>ппц, у тебя вроде ж вроде должно быть понимание принципов разработки ПО, но такой бред несешь
У меня не только "понимание принципов", но еще и значительный опыт, в том числе и в "разработке архитектур" (С), и сертификация scrum coach, а также product owner. Так что я-то как раз знаю, о чем говорю. Другое дело что трактаты на форуме писать глупо, это нужно на конференциях и в блогах, а не здесь.
Здравствуйте, 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" или какими-то ещё сферическими попугаями в условном вакууме.
Здравствуйте, SkyDance, Вы писали:
SD>сертификация scrum coach, а также product owner
Сорри, но это совсем не те вещи, которые как то помогают с архитектурой.
SD>Другое дело что трактаты на форуме писать глупо, это нужно на конференциях и в блогах, а не здесь.
Если для ответа на базовые вопросы тебе требуется писать трактаты, то это прямо свидетельствует об отсутствии четкого понимания.
Здравствуйте, SkyDance, Вы писали:
SD>У меня не только "понимание принципов", но еще и значительный опыт, в том числе и в "разработке архитектур" (С), и сертификация scrum coach, а также product owner. Так что я-то как раз знаю, о чем говорю. Другое дело что трактаты на форуме писать глупо, это нужно на конференциях и в блогах, а не здесь.
Те гениальные мысли что ты тут пишешь заставляют усомниться в
не только "понимание принципов", но еще и значительный опыт
Здравствуйте, SkyDance, Вы писали:
SD>Вот видишь, это вполне конкретный сценарий. У него есть ничуть не менее конкретный business value — "несколько месяцев вхождения".
Но стейкхолдеру ты это не продашь.
Поэтому тут обычно бывает два варианта: либо ликвидацию техдолга впихивают в конкретную задачу, которая на самом деле имеет business value, либо заранее оговаривают, что Х% спринта тратится командой на техдолг.
SD>Это вполне укладывается в Scrum. И почему-то мне кажется, что сие не будет монолитной задачей на 3 спринта всей команды
Это смотря какой техдолг. У меня тут была история. Есть некий внутренний сервис, на который мой сервис завязан. В какой то момент та команда, которая им занимается, решила его переписать from scratch. Так вот, процесс переезда на него моего сервиса занят 7 спринтов (3 спринта борьба с breaking changes и 4 — отлавливание в их сервисе багов и импорт данных). При этом функционал внешне ни капельки не изменился, и с точки зрения стейкхолдеров никакой бизнес ценности непосредственно в переходе нет.
Ценность появится потом, когда на базе новой версии нового сервиса будут реализованы новые фичи.
SD>Не вижу связи между вашим пониманием и архитектурой. Чтобы понимать коммиты, нужно уметь читать код.
чем больше модульность — тем проще модули (это упрощенно конечно)
SD>Устами младенца глаголет истина. SD>Если "всякие тут бины" не несут измеримой пользы, значит, их нужно выкидывать.
почти все java web-app тем не менее пишут с ними. чего ж так
Здравствуйте, Hard_Club, Вы писали:
НС>>Это как то финансово выражается? H_C>а как финансово выражается разрешить команде писать спагетти-монстры, лишбы было что показать
Иногда такое имеет смысл. Например для MVP. Так что насчет ответа на вопрос?
НС>Сорри, но это совсем не те вещи, которые как то помогают с архитектурой.
Так и вопрос не про архитектуру, а про то, как правильно сформулировать задачи.
НС>Если для ответа на базовые вопросы тебе требуется писать трактаты, то это прямо свидетельствует об отсутствии четкого понимания.
Для ответа на базовый вопрос "что есть E=mc2" некоему Эйнштейну потребовалось два трактата. СТО/ОТО.
Значит, на данном этапе это не нужно. Станет нужно — тогда и следует сделать.
Это основной принцип Agile, делать только то, что нужно сейчас, а не то, что может стать нужным через год. Потому что через год может поменяться абсолютно все, а уж "высеченная в коде архитектура" и вовсе станет непохожа на изначально запланированную.
НС>Поэтому тут обычно бывает два варианта: либо ликвидацию техдолга впихивают в конкретную задачу, которая на самом деле имеет business value, либо заранее оговаривают, что Х% спринта тратится командой на техдолг.
Прекрасно. Именно так и следует поступать. Но в оригинальном после речь идет про "задача на три спринта, неделимая на составные части". Я в такое не верю.
НС>При этом функционал внешне ни капельки не изменился, и с точки зрения стейкхолдеров никакой бизнес ценности непосредственно в переходе нет. НС>Ценность появится потом, когда на базе новой версии нового сервиса будут реализованы новые фичи.
Боюсь показаться циником, но... а что, если ценность не появится? Или аналогичную ценность можно было получить без тотального переписывания? Эх, кабы нам всем по хрустальному шару, да чтоб знать заранее. Но...
N>action item оно становится, когда его согласны принять в работу. Или в твоём диалекте это что-то другое?
An action item is a discrete task that must be accomplished, usually by a single individual or a small team or group. Action items typically arise from meetings and should always be clearly documented. Most people overestimate how well they are likely to remember things.
Совсем не обязательно быть "принятой в работу". Достаточно понимания, что это actionable, и что именно нужно сделать, а не просто поговорить.
N>Ты вот про "значительный опыт" рассказываешь, а читаешь у собеседника что-то совсем не то, что он писал прямым текстом.
У собеседника написано вот что:
А что если проработка дизайна займет 3 спринта (например, разработка нового алгортма, изучение того что есть). Как это все оформлять?
N>Ещё раз: "чистая архитектура" предназначается для того, чтобы как раз не попадать в ситуацию с высоким порогом вхождения и с необходимостью распутывания перед тем, как начать делать реально что-то полезное.
Это может входить в противоречие с интересами заказчика. Которому может быть нужен рабочий прототип. Очень часто случается, что наличие такого прототипа снимает дальнейшие вопросы (и закрывает проект к чертовой бабушке). Поэтому нежелание заказчика вкладываться в научную составляющую (включая "чистую архитектуру") можно понять.
N>Как вы режете у себя на storypoints — это ваше дело. Но я вместе со многими другими предпочитаю таки считать в единицах рабочего времени среднего участника, и не связывать с "минимальными задачами по DoD" или какими-то ещё сферическими попугаями в условном вакууме.
И что, у вас "единица рабочего времени" совпадает с "реальной единицей работы"?
Нарезка SP потому и нужна, что оценить задачу в человеко-часах подавляющее большинство разработчиков не могут. Не потому, что плохие, а потому, что слишком много неопределенного. Зато могут оценить прикидочно — "вот та фича сложнее этой в 2, 4, 8, ... раз".
Здравствуйте, SkyDance, Вы писали:
НС>>Сорри, но это совсем не те вещи, которые как то помогают с архитектурой. SD>Так и вопрос не про архитектуру, а про то, как правильно сформулировать задачи.
Не не не, ты сделал заявление по поводу самой архитектуры, а не по поводу формулирования задачи.
НС>>Если для ответа на базовые вопросы тебе требуется писать трактаты, то это прямо свидетельствует об отсутствии четкого понимания. SD>Для ответа на базовый вопрос "что есть E=mc2" некоему Эйнштейну потребовалось два трактата. СТО/ОТО.
Так то — с подробностями и формулами. А основные принципы вполне укладываются в формуный формат.
Здравствуйте, SkyDance, Вы писали:
SD>В первую очередь, прекратить считать заказчика идиотом. И делать то, что ему нужно, а не то, чего бы вам хотелось. SD>Тогда, внезапно, окажется, что наличие или отсутствие "чистой архитектуры" не влияет.
Чистой не влияет, а качество кода, которое сильно зависит от качества архитектуры влияет на стоимость разработки напрямую. Что такое чистая — непонятно, мой опыт говорит, что в любой архитектуре всегда есть определенная доля компромисов и некий набор фич, которые вписываются в нее достаточно плохо.
Под качеством кода я понимаю его читабельность, тестируемость, SRP и устойчивость к изменению других модулей.
Твою мысль я понимаю, заказчику в целом пофиг на то, что в его продукте плохая архитектура. Ему важна возможность платить за измеримые показатели. Но и задача инженера уметь показать измеримую выгоду от улучшения архитектуры, а не вставать в позицию "играю как умею теми картами, что раздали".
Здравствуйте, Hard_Club, Вы писали:
H_C>есть проекты где без чистой архитектуры через год новая фича будет стоить как самолет. как это донести до заказчика
А можно пример такого проекта? Мой опыт говорит о том, что за спринт что-то рабочее в нормальной архитектуре можно показать всегда.
Здравствуйте, SkyDance, Вы писали:
SD>Нарезка SP потому и нужна, что оценить задачу в человеко-часах подавляющее большинство разработчиков не могут. Не потому, что плохие, а потому, что слишком много неопределенного. Зато могут оценить прикидочно — "вот та фича сложнее этой в 2, 4, 8, ... раз".
Вопрос немного в сторону. Мне непонятно, если задачи оцениваются в SP и на спринт набрали, например, 60 SP, почему спринт ограничивается двумя неделями? Почему не выполнять спринт до тех пор, пока все 60 SP не будут выполнены? Это может быть и быстрее и дольше 2-х недель. Т.е. с одной стороны мы пытаемся оценивать задачи в SP, но с другой привязываемся к времени выполнения, двум неделям. Вот это мне непонятно.
НС>Не не не, ты сделал заявление по поводу самой архитектуры, а не по поводу формулирования задачи.
Сделать заявление по поводу чего-то, чего еще нет, решительно невозможно. Мои ответы относятся только к изначальной задаче, и к попыткам осознать, для чего же заказчику может быть нужно потратить 3 спринта команды. Когда это станет ясно, тогда будет видно и как это оформить.
НС>Так то — с подробностями и формулами. А основные принципы вполне укладываются в формуный формат.
Основные принципы я уже дал. По ссылкам. Поскольку этого явно недостаточно, дальнейшие пояснения потребуют уже очень много времени, которого, увы, у меня нет.
Z>Чистой не влияет, а качество кода, которое сильно зависит от качества архитектуры влияет на стоимость разработки напрямую.
Какие у вас есть метрики, показывюащие "влияние архитектуры на качество кода"?
Если эти метрики показывают, сколько времени уходит впустую из-за отсутствия оной архитектуры, это прекрасный пример того, что можно вставить в следующий же спринт. Ибо есть business value и есть оценка "сколько делать".
Z>Твою мысль я понимаю, заказчику в целом пофиг на то, что в его продукте плохая архитектура. Ему важна возможность платить за измеримые показатели.
Совершенно верно. Даже если этот показатель — "удовлетворенность инженеров". Которая может вырасти от наличия архитектурного документа (а может и упасть — но пока это не измеряется, показателя не существует, а значит, и платить не за что).
Z> Но и задача инженера уметь показать измеримую выгоду от улучшения архитектуры, а не вставать в позицию "играю как умею теми картами, что раздали".
Насколько я понял первое сообщение, речь идет не об "улучшении архитектуры", а о попытке "продать" заказчику первые 3 спринта как "исследуем нечто монолитное, и никакого результата не будет раньше чем через 3 спринта". На месте заказчика я бы поостерегся на такое подписываться.
Другое дело если там расписано, чем именно будут заняты эти 3 спринта, что будет результатом каждого из спринтов, и по каким критериям заказчик будет эти результаты принимать. В общем, обычный Скрам.
P>Вопрос немного в сторону. Мне непонятно, если задачи оцениваются в SP и на спринт набрали, например, 60 SP, почему спринт ограничивается двумя неделями?
.
P> Почему не выполнять спринт до тех пор, пока все 60 SP не будут выполнены? Это может быть и быстрее и дольше 2-х недель.
Потому что сложно планировать митинги, особенно demo (и последующую retrospective). Все-таки заказчик должен знать, когда он что-то получит. Если у вас каждые 2 недели с 14:00 до 15:00 запланирован демо-митинг, где заказчик принимает сделанные сценарии, это удобно. Даже банально забронировать переговорку — и то удобство.
P> Т.е. с одной стороны мы пытаемся оценивать задачи в SP, но с другой привязываемся к времени выполнения, двум неделям. Вот это мне непонятно.
Все верно. По результатам фиксированного временнОго промежутка (2 недели) вычисляем реальную производительность (velocity). И не пытаемся "впихнуть невпихуемое" в следующий спринт, а реалистично оцениваем, сколько SP брать.
