В классическом Скрам, (таком, о котором говорят его создатели), не найти ни спецификаций, ни описания вариантов использования (use cases), ни, тем более, документов с пугающим словом ТЗ. Вся работа по проекту построена вокруг небольших по размеру, понятных каждому участнику проекта пожеланий, которые легко оцениваются, легко обсуждаются с заказчиком и которые можно реализовать в рамках короткой итерации продолжительностью одну-две недели.
OpenUP - это экономичный унифицированный процесс, использующий принципы итеративности и инкрементальности в рамках структурированного жизненного цикла. OpenUP использует прагматичную философию гибкой разработки, которая имеет в своей основе коллективный подход к разработке программного обеспечения. Это независимый от инструментов, мало регламентированный процесс, который можно расширить для адаптации к широкому диапазону типов проектов.
Зачастую получается так, что есть несколько выделенных архитекторов (уровня предприятия, процессов, данных, интеграционных и т.п.), на которые приходится десяток команд по 10 - 20 человек в каждой. Вопрос состоит в том, как архитекторам стать вовлеченными во все эти проекты, в условиях ограниченного рабочего дня, как заставлять команду следовать правилам в организации кода, если сразу же возникает масса конфликтов с командами, работающими в рамках Agile. Как учесть нефункциональные требования, о которых заказчик может и не задумываться?
Команды, разрабатывающие программное обеспечение бывают разные, но в целом они схожи в том, что идеальных разработчиков, супер-профессионалов, в них бывает слишком мало, либо не бывает вовсе. Отчасти по этой причине возникает проблема с передачей качественных (проверенных) сборок на тестирование. Из-за периодической регрессии весь процесс разработки начинает буксовать и отдаляет команду от сдачи проекта в намеченные сроки. Есть проверенная методика, при которой подобные проблемы можно свести к минимуму - перед передачей сборки в тестирование проводить проверку сборки силами самих разработчиков. То есть организовать процесс предварительной проверки сборки, а не надеяться на то, что разработчики проверят свой и смежный функционал.
