Pull to refresh

Comments 10

проекты по Scrum

Вот на самом деле откуда все мифы про Agile — из-за попыток подменить практики и методологии управления проектами на практики и методологии по разработке продукта.

Успешный продукт и успешный проект — это разные истории. Ни XP ни Scrum сами по себе не гарантируют успешность проекта, а лишь повышают вероятность получения успешного продукта.
Даже если их не скрещивать, все-равно все что выведено за скобки методологии просто забывается и перестает применяться. Консультанты Scrum говорят "как общаться", но не говорят "что нужно сделать чтобы получить качественный код."

так а Scrum действительно на другие аспекты разработки нацелен, нет смысла говорить о том, что построить дом, используя только молоток (Scrum) — невозможно, нужны еще материалы, другие инструменты, проектная документация и здравый смысл.
Q: А бывают ли проекты по Scrum успешными?
A: Только если они делаются с применением практик XP. Или в случае если весь проект выполняется менее чем за 1 месяц под ключ.

Все пацаны, сворачиваемся, а то растянули тут все на полтора месяца…
Очень спорное утверждение, согласен. Мьі вот на 2 года уже растянули. И почему-то не страдаем.
Методология — методологией, но всегда нужно включать голову и выстраивать правильную сетку (иерархию) приоритетов и иметь в виду то, что реальной жизни вообще все-равно, как ты это делаешь (хоть задом наперед код пиши) SCRUM — это такой же подход, как и, своего рода, привычка инкапсулировать код в классы, пэкэджи и тп. Да — круто, да — удобно. Но это всего лишь способ получения результата, который не гарантирует ровным счетом ничего. Почитать полезно, знать — тоже полезно, но не более.
Посылки были иначально ложными.
80% требований исходят из предметной области, они практически не меняются. И только 20% связаны с персонализацией под заказчика.
Но для этого нужно знать предметные области на системном уровне.
Меняются не требования, а представления исполнителей о предметной области, процесс изучения которой прячется под бесконечный цикл разработки.
И какой вывод? Мифы рождаются из других причин?
cross_join — Отчасти согласен и про представления и про изучение. Но предприниматель реально может перекомпоновать на ходу свой бизнес и это повлечет сильно изменение. Предприниматель действует по факту на угад (риск на основе по прогнозов маркетологов) и он перестраивается под рынок и меняет требования. По этому ключевой фишкой scrum является не методология, а скидывание ответственности на product owner. А этот самый Owner — это не PM из команды (актер играющий роль), а реальный заказчик (мотивация другая).
Если разрабатываем компонент для ракеты, которую 3 года проектировал НИИ — там конечно другое дело, можно говорить, кто кто-то что-то недопонял и накосячил. Тут и водападить не грех.
У водопадов и аджйлов практически одинаковый масштаб применения, ограниченный одной предметной областью. Пакеты и системы на стыке нескольких областей вызывают зацикливание процесса. У водопада — на этапах анализа и проектирования, у аджайлов — на кодировании.
Исторически то, что сейчас называют аджайлами — это просто восходящяя разработка с оберткой в разные ритуалы.
Водопад — нисходящая.
Проблемы обоих подходов решали в 1980-е, когда появились спиральные методики (RUP, MSF).

Sign up to leave a comment.