Цитаты из книги «Софт за 30 дней. Как Scrum делает невозможное возможным»

Мы можем очень четко описать определенные аспекты того, как программное обеспечение должно работать, и требования, которым оно должно соответствовать. Но есть и менее очевидные аспекты программного обеспечения — их можно на какое-то время оставить неопределенными. Все, что нам известно, мы ранжируем: от критически важного и хорошо понятного до, возможно, имеющего отношение к проекту и смутно понятного. Мы создаем список идей, который называем бэклог, или требования

в случае с программным обеспечением в течение такого долгого периода накапливается слишком много рисков и потерь. Вместо этого мы используем короткие периоды, обычно 30 дней или меньше. (Позднее мы обсудим значение более коротких периодов.) По окончании первых 30 дней проверяем результаты и определяем, что делать дальше для достижения нашего видения, и, если необходимо, вносим изменения.

Если наша цель — разработка системы с определенными признаками или функционалом, то мы должны проверять то, что составляет часть этого признака, функции или их сочетания.

Прозрачность. Когда мы проводим проверку, то должны иметь возможность оценить, что мы видим в тех же условиях, в которых находится наша

Проверка и адаптация. Следует часто проверять, где мы сейчас, чтобы адаптировать следующие шаги и добиться оптимальных результатов. Частота проверок и адаптаций зависит от того, какие риски мы готовы принять. Чем больше неизвестных, тем быстрее мы может отклониться от цели. Чем дальше мы уходим от цели, тем больше потеряем на изменении курса, переделке того, что сделано неверно, или выполнении работы сначала.

Переход к Scrum, эмпирическому процессу, значительно увеличивает шансы на успешное завершение проекта разработки программного обеспечения.

Множество небольших команд разработчиков выбирают наиболее важные требования для каждой итерации и превращают их в часть готового к употреблению программного обеспечения. Все эти части затем объединяются в одну полностью законченную и готовую к применению программу. В конце каждой последующей итерации другие части и надстройки программы добавляются к существующему функционалу.

При частой смене требований бизнеса и технологий, которые присутствуют в реальных условиях, очень редко встречается, чтобы все элементы проекта оставались неизменными. Как результат, о чем и сообщает отчет The Standish Group, 86% проектов по разработке программного обеспечения, основанных на предиктивных процесах, неуспешны.

Если кто-то может создать окончательное видение, определить все требования к нему и затем разработать детальный план по воплощению их в жизнь, тогда предиктивный процесс будет эффективным.

предиктивным, или последовательным.