Видите ли, я занимаюсь разработкой софта больше 20 лет. Формально даже больше 25, но думаю те проекты можно всерьез не считать. И я ни разу не видел проект, на котором скрам не работал бы или не мог работать. И наоборот, оглядываясь на проекты, где использовалось «жесткое» планирование с подробной проектной документацией и подробным планом — я понимаю скольких проблем нам бы помог избежать скрам/эджайл. И, опять же, не могу вспомнить ни одного более-менее крупного проекта, где все эти подробные планы не пошли бы по одному месту по причине изменений в хотелках заказчика. Внешнего ли, внутреннего ли.
Что касается «людей со стеклянными глазами» — ну да, сталкивался, конечно. Но, опять же, это не проблема скрама как метода. Если человек не понимает методологии или не умеет пользоваться — это проблема данного конкретного человека. Ровно та же самая проблема возникнет и при использовании других подходов. Если человек не умеет — он с высокой вероятностью нагородит фигни. И да, намного хуже когда человек не осознает, что он не умеет и со «стеклянными глазами» лепит что-то в рамках своего недопонимания.
Разумеется все это относительно разработки софта. В других отраслях скрам вполне может быть не применим или неэффективен в сравнении с другими подходами.
У вас причина со следствием перепутана. Скрам не предполагает «подсовывание», наоборот, он придуман для работы в условиях, когда «доделанный» функционал невозможно сделать сразу, потому что заказчик сам не представляет до конца что это. Если бы заказчик был способен на старте полностью, ясно и точно, определить и сформулировать свои хотелки — скрам бы попросту не понадобился. Но он не может, поэтому пришлось придумывать все эти методики итеративной разработки.
Я вам не мешаю спорить с воображаемым собеседником? Где тут про «проблемы заказчика»? Если нет четкого видения результата — невозможна оценка сроков. Это просто реальность, данная нам в ощущениях, безотносительно скрама, эджайла и проблем заказчика. Просто вселенная так устроена, что если требования к задаче постоянно меняются и дополняются, то срок выполнения задачи постоянно растет и все оценки идут под хвост.
Дело не в том как обойти грабли. Дело в том сколько новых граблей можно найти собственным лбом пытаясь следовать принципу «самолеты так не строят». И в том, что большинство граблей, которые вы называете — это вообще не грабли скрама. Если у заказчика нет четкого, до мельчайших деталей видения результата (а это практически всегда) — бессмысленно говорить об оценке сроков всего проекта. Разве что очень приближенная, на эмпириках вроде «ну вот для конторы Х делали примерно то же самое, уложились в год».
Прям по пунктам:
Полезная функциональность
Бесполезно притягивать за уши аналогии со сбором самолета или строительством дома. И то и другое делается по подробнейшей и практически неизменной (в процессе) проектной документации. Если у вас есть заказчик, готовый дать такой документ на софт-проект — вы умерли и попали в Вальгаллу для программистов. Поэтому в строительстве вполне хорошо работают старые добрые диаграммы Ганта, но попытки использовать этот подход в ПО превращаются в смердящий ужас.
Вовлеченность заказчика
Если заказчик не готов предоставить человека, принимающего участие в проекте — заказчик по дефолту идет нафиг. Такой проект изначально обречен на внезапные и болезненные переделки, дрязги, недовольство и пр. Никто, кроме заказчика не знает чего он хочет и как он это видит. Если у заказчика есть подробнейший проект — см. выше.
Оценка задач
Тут уже элементарное непонимание методологии скрама. Никто не запрещает декомпозировать задачу на куски, которые в отдельности могут не добавлять ценности продукту. Нормальная практика, когда есть story, которая добавляет ценность, но внутри она декомпозирована на отдельные таски. Можно даже таски не заносит, просто для себя на бумажке декомпозировать и посчитать. Это вообще не проблема скрама.
Оценка сроков
Для того чтобы оценить конечный срок нужен детальный проект, который не будет меняться в процессе. А он — см. выше.
Ну и так далее.
Что касается «людей со стеклянными глазами» — ну да, сталкивался, конечно. Но, опять же, это не проблема скрама как метода. Если человек не понимает методологии или не умеет пользоваться — это проблема данного конкретного человека. Ровно та же самая проблема возникнет и при использовании других подходов. Если человек не умеет — он с высокой вероятностью нагородит фигни. И да, намного хуже когда человек не осознает, что он не умеет и со «стеклянными глазами» лепит что-то в рамках своего недопонимания.
Разумеется все это относительно разработки софта. В других отраслях скрам вполне может быть не применим или неэффективен в сравнении с другими подходами.
Полезная функциональность
Бесполезно притягивать за уши аналогии со сбором самолета или строительством дома. И то и другое делается по подробнейшей и практически неизменной (в процессе) проектной документации. Если у вас есть заказчик, готовый дать такой документ на софт-проект — вы умерли и попали в Вальгаллу для программистов. Поэтому в строительстве вполне хорошо работают старые добрые диаграммы Ганта, но попытки использовать этот подход в ПО превращаются в смердящий ужас.
Вовлеченность заказчика
Если заказчик не готов предоставить человека, принимающего участие в проекте — заказчик по дефолту идет нафиг. Такой проект изначально обречен на внезапные и болезненные переделки, дрязги, недовольство и пр. Никто, кроме заказчика не знает чего он хочет и как он это видит. Если у заказчика есть подробнейший проект — см. выше.
Оценка задач
Тут уже элементарное непонимание методологии скрама. Никто не запрещает декомпозировать задачу на куски, которые в отдельности могут не добавлять ценности продукту. Нормальная практика, когда есть story, которая добавляет ценность, но внутри она декомпозирована на отдельные таски. Можно даже таски не заносит, просто для себя на бумажке декомпозировать и посчитать. Это вообще не проблема скрама.
Оценка сроков
Для того чтобы оценить конечный срок нужен детальный проект, который не будет меняться в процессе. А он — см. выше.
Ну и так далее.