Про декомпозицию неделимых задач
В вашей работе встречаются задачи, которые занимают несколько спринтов просто потому, что выглядят неделимыми? Я знаю, что с ними делать. Особенно, если это касается разработки.
В вашей работе встречаются задачи, которые занимают несколько спринтов просто потому, что выглядят неделимыми? Я знаю, что с ними делать. Особенно, если это касается разработки.
А возможно-ли какая-нибудь оценка эффективности всех описанных подходов?
Я разработчик и последние полгода работаю с тем что соответствует описанному "Итеративно-инкрементальных подход", и у меня ощущение падение своей продуктивности раза в 3.
Связываю я это как раз с тем что есть огромные затраты времени (и сил команды!) на планирования/митинги/и т.д. и т.д.
Статья делает упор на то что прозрачные сроки это круто, но платой за это может быть значительное замедление реализации.
Кажется очень важным понимание а правда ли проекту на стадии достижения МВП нужно следовать лучшим практикам?
* Возможно автор не имел ввиду никакой серебряной пули, которую я тут увидел.
Серебряной пули действительно нет: начиная с того, что предварительное исследование дается не бесплатно, заканчивая тем, что не каждой команде нужна прозрачность (ее наличие или отсутствие ни на что не влияет). При этом, работа водопадами и итерациями - не предполагает наличие/отсутствие конкретных встреч на митинги/планирование и пр. При непрозрачном водопаде встречаться только в начале каждого этапа, а при итерациях забить каждый рабочий день встречами, но верно и обратное. Поэтому одно не является следствием другого.