Scrum предусматривает что-то рабочее в конце спринта. А что если проработка дизайна займет 3 спринта (например, разработка нового алгортма, изучение того что есть). Как это все оформлять?
Здравствуйте, Hard_Club, Вы писали:
H_C>Scrum предусматривает что-то рабочее в конце спринта. А что если проработка дизайна займет 3 спринта (например, разработка нового алгортма, изучение того что есть). Как это все оформлять?
Значит, результатом будет отчёт за спринт. Чудес не бывает
Нас просят резать задачи кусками пол-спринта максимум, чтобы можно было планировать, набивая "рюкзак".
Здравствуйте, Hard_Club, Вы писали:
H_C>Scrum предусматривает что-то рабочее в конце спринта. А что если проработка дизайна займет 3 спринта (например, разработка нового алгортма, изучение того что есть). Как это все оформлять?
А зачем вы каскадную по сути работу пытаетесь в scrum засунуть?
H_C>Scrum предусматривает что-то рабочее в конце спринта. А что если проработка дизайна займет 3 спринта (например, разработка нового алгортма, изучение того что есть). Как это все оформлять?
Здравствуйте, Hard_Club, Вы писали:
H_C>Scrum предусматривает что-то рабочее в конце спринта.
Не то чтобы прям обязательно, но стейкхолдерам желательно что то показать.
H_C> А что если проработка дизайна займет 3 спринта (например, разработка нового алгортма, изучение того что есть).
Что, вот прям всем тимом проработка дизайна?
H_C> Как это все оформлять?
H_C>Scrum предусматривает что-то рабочее в конце спринта. А что если проработка дизайна займет 3 спринта (например, разработка нового алгортма, изучение того что есть). Как это все оформлять?
Не бывает единых монолитных задач типа "проработать дизайн и архитектуру". Эти задачи состоят из каких-то более маленьких сценариев. Более того, сам по себе Scrum не предполагает генерацию бессмысленных артефактов (таких как "дизайн и архитектура"), поскольку сии артефакты не несут пользы заказчику (у них нет business value). Единственное исключение — "внутренний заказчик", который должен каким-то образом оценить пользу (business value) данного артефакта или набора артефактов. Но тогда сей заказчик должен понимать, во сколько ему обойдется это желание иметь "архитектуру и дизайн". Коли будет три спринта, значит, ценность такой документации должна как минммум равняться выручке, которую принесли бы фичи, реализованные *вместо* "архитектуры и дизайна".
SD>Не бывает единых монолитных задач типа "проработать дизайн и архитектуру". Эти задачи состоят из каких-то более маленьких сценариев. Более того, сам по себе Scrum не предполагает генерацию бессмысленных артефактов (таких как "дизайн и архитектура"), поскольку сии артефакты не несут пользы заказчику (у них нет business value). Единственное исключение — "внутренний заказчик", который должен каким-то образом оценить пользу (business value) данного артефакта или набора артефактов. Но тогда сей заказчик должен понимать, во сколько ему обойдется это желание иметь "архитектуру и дизайн". Коли будет три спринта, значит, ценность такой документации должна как минммум равняться выручке, которую принесли бы фичи, реализованные *вместо* "архитектуры и дизайна".
есть проекты где без чистой архитектуры через год новая фича будет стоить как самолет. как это донести до заказчика
Здравствуйте, Hard_Club, Вы писали:
H_C>есть проекты где без чистой архитектуры через год новая фича будет стоить как самолет.
Нет такой архитектуры — чистой. Любая архитектура в процессе эволюции обязательно засрется и станет неадекватной. Единственный выход — писать код так чтобы его архитектуру можно было менять как можно легче.
H_C>есть проекты где без чистой архитектуры через год новая фича будет стоить как самолет. как это донести до заказчика
В первую очередь, прекратить считать заказчика идиотом. И делать то, что ему нужно, а не то, чего бы вам хотелось.
Тогда, внезапно, окажется, что наличие или отсутствие "чистой архитектуры" не влияет.
Мне известно одно применение "чистой архитектуры". Это когда менеджеры хотят раздуть свой штат (а значит и ценность) путем найма десятка обезъян вместо трех хороших разработчиков. И под этим соусом пропихивается "нам нужна архитектура, потому что иначе обезьяны не работают".
SD>В первую очередь, прекратить считать заказчика идиотом. И делать то, что ему нужно, а не то, чего бы вам хотелось. SD>Тогда, внезапно, окажется, что наличие или отсутствие "чистой архитектуры" не влияет.
хорошо, мне лиду с такой чистой архитектурой проще понимать комиты. А не о-боже как это работает.
С таким подходом можно например в web-проектах выбрасить спринг например. А то понапридумывали бины всякие тут.
H_C>хорошо, мне лиду с такой чистой архитектурой проще понимать комиты. А не о-боже как это работает.
Не вижу связи между вашим пониманием и архитектурой. Чтобы понимать коммиты, нужно уметь читать код.
H_C>С таким подходом можно например в web-проектах выбрасить спринг например. А то понапридумывали бины всякие тут.
Устами младенца глаголет истина.
Если "всякие тут бины" не несут измеримой пользы, значит, их нужно выкидывать.
Здравствуйте, SkyDance, Вы писали:
SD>Мне известно одно применение "чистой архитектуры". Это когда менеджеры хотят раздуть свой штат (а значит и ценность) путем найма десятка обезъян вместо трех хороших разработчиков. И под этим соусом пропихивается "нам нужна архитектура, потому что иначе обезьяны не работают".
ппц, у тебя вроде ж вроде должно быть понимание принципов разработки ПО, но такой бред несешь
Здравствуйте, SkyDance, Вы писали:
SD>Мне известно одно применение "чистой архитектуры". Это когда менеджеры хотят раздуть свой штат (а значит и ценность) путем найма десятка обезъян вместо трех хороших разработчиков. И под этим соусом пропихивается "нам нужна архитектура, потому что иначе обезьяны не работают".
Я бы согласился. Но я видел проекты, которые запутаны как раз обезьянами до такой степени, что чтобы с ними что-то полезное сделать, надо вначале их распутать. А это таки проблема.
Поэтому я предпочту хотя бы частично, но ту самую "чистую архитектуру" таки начать реализовывать. Всегда полезно иметь экономию в несколько недель или месяцев вхождения в тематику...
