Comments 10
проекты по Scrum
Вот на самом деле откуда все мифы про Agile — из-за попыток подменить практики и методологии управления проектами на практики и методологии по разработке продукта.
Успешный продукт и успешный проект — это разные истории. Ни XP ни Scrum сами по себе не гарантируют успешность проекта, а лишь повышают вероятность получения успешного продукта.
+1
Даже если их не скрещивать, все-равно все что выведено за скобки методологии просто забывается и перестает применяться. Консультанты Scrum говорят "как общаться", но не говорят "что нужно сделать чтобы получить качественный код."
0
Q: А бывают ли проекты по Scrum успешными?
A: Только если они делаются с применением практик XP. Или в случае если весь проект выполняется менее чем за 1 месяц под ключ.
Все пацаны, сворачиваемся, а то растянули тут все на полтора месяца…
A: Только если они делаются с применением практик XP. Или в случае если весь проект выполняется менее чем за 1 месяц под ключ.
Все пацаны, сворачиваемся, а то растянули тут все на полтора месяца…
0
Очень спорное утверждение, согласен. Мьі вот на 2 года уже растянули. И почему-то не страдаем.
0
Методология — методологией, но всегда нужно включать голову и выстраивать правильную сетку (иерархию) приоритетов и иметь в виду то, что реальной жизни вообще все-равно, как ты это делаешь (хоть задом наперед код пиши) SCRUM — это такой же подход, как и, своего рода, привычка инкапсулировать код в классы, пэкэджи и тп. Да — круто, да — удобно. Но это всего лишь способ получения результата, который не гарантирует ровным счетом ничего. Почитать полезно, знать — тоже полезно, но не более.
+1
Посылки были иначально ложными.
80% требований исходят из предметной области, они практически не меняются. И только 20% связаны с персонализацией под заказчика.
Но для этого нужно знать предметные области на системном уровне.
Меняются не требования, а представления исполнителей о предметной области, процесс изучения которой прячется под бесконечный цикл разработки.
80% требований исходят из предметной области, они практически не меняются. И только 20% связаны с персонализацией под заказчика.
Но для этого нужно знать предметные области на системном уровне.
Меняются не требования, а представления исполнителей о предметной области, процесс изучения которой прячется под бесконечный цикл разработки.
+1
И какой вывод? Мифы рождаются из других причин?
0
cross_join — Отчасти согласен и про представления и про изучение. Но предприниматель реально может перекомпоновать на ходу свой бизнес и это повлечет сильно изменение. Предприниматель действует по факту на угад (риск на основе по прогнозов маркетологов) и он перестраивается под рынок и меняет требования. По этому ключевой фишкой scrum является не методология, а скидывание ответственности на product owner. А этот самый Owner — это не PM из команды (актер играющий роль), а реальный заказчик (мотивация другая).
Если разрабатываем компонент для ракеты, которую 3 года проектировал НИИ — там конечно другое дело, можно говорить, кто кто-то что-то недопонял и накосячил. Тут и водападить не грех.
Если разрабатываем компонент для ракеты, которую 3 года проектировал НИИ — там конечно другое дело, можно говорить, кто кто-то что-то недопонял и накосячил. Тут и водападить не грех.
0
У водопадов и аджйлов практически одинаковый масштаб применения, ограниченный одной предметной областью. Пакеты и системы на стыке нескольких областей вызывают зацикливание процесса. У водопада — на этапах анализа и проектирования, у аджайлов — на кодировании.
Исторически то, что сейчас называют аджайлами — это просто восходящяя разработка с оберткой в разные ритуалы.
Водопад — нисходящая.
Проблемы обоих подходов решали в 1980-е, когда появились спиральные методики (RUP, MSF).
Исторически то, что сейчас называют аджайлами — это просто восходящяя разработка с оберткой в разные ритуалы.
Водопад — нисходящая.
Проблемы обоих подходов решали в 1980-е, когда появились спиральные методики (RUP, MSF).
0
Sign up to leave a comment.
Откуда мифы про Agile