Здравствуйте, SkyDance, Вы писали:
SD>Какие у вас есть метрики, показывюащие "влияние архитектуры на качество кода"? SD>Если эти метрики показывают, сколько времени уходит впустую из-за отсутствия оной архитектуры, это прекрасный пример того, что можно вставить в следующий же спринт. Ибо есть business value и есть оценка "сколько делать".
У меня лично таких метрик нет. Если у меня закрадывается подозрение, что можно удешевить разработку с помощью улучшения архитектуры я либо полагаюсь на интуицию либо на недорогие эксперименты. Но я рискую своими деньгами, мне за архитектуру не платят.
SD>Насколько я понял первое сообщение, речь идет не об "улучшении архитектуры", а о попытке "продать" заказчику первые 3 спринта как "исследуем нечто монолитное, и никакого результата не будет раньше чем через 3 спринта". На месте заказчика я бы поостерегся на такое подписываться.
SD>Другое дело если там расписано, чем именно будут заняты эти 3 спринта, что будет результатом каждого из спринтов, и по каким критериям заказчик будет эти результаты принимать. В общем, обычный Скрам.
Здравствуйте, prog123, Вы писали:
P>Вопрос немного в сторону. Мне непонятно, если задачи оцениваются в SP и на спринт набрали, например, 60 SP, почему спринт ограничивается двумя неделями? Почему не выполнять спринт до тех пор, пока все 60 SP не будут выполнены?
Смысл спринтов в борьбе с неопределенностями. Вместо того чтобы строить длинные планы, которые обязательно будут нарушены, мы строим планы со сроками только на короткий спринт, получая некоторую определенность. А если спринт длится как повезет, то его смысл попросту теряется. В этом случае проще взять голый канбан и не морочится со спринтами вообще.
Здравствуйте, Hard_Club, Вы писали:
НС>>Иногда такое имеет смысл. Например для MVP. Так что насчет ответа на вопрос? H_C>управление сложностью. как его выразишь.
Ну то есть объяснить зачем это нужно заказчику ты не можешь. ЧТД.
H_C>для MVP что немного падает — это ок?
