Перечислим преимущества и недостатки подхода Scrum, которые мы только что обсудили. Прежде всего, это простые практики и простые артефакты. Т. е. на самом деле, менеджмент с формальной точки зрения управления проектами не требует каких-то специальных знаний. Но в команде существует так называемый scrum-мастер, который является модератором или фасилитатором, т. е. человеком, который поддерживает процесс разработки, но формально не является руководителем. Это человек очень важный, это человек, который имеет некие неформальные познания, некий неформальный опыт в не одном, как правило, scrum-проекте, который может достаточно гибко вести команду к успеху. Поэтому руководство в основном неформально. Артефакты, как мы понимаем, простые — это достаточно короткие карточки user stories, на которых излагается функционально в одно предложение то, что должен, прежде всего, делать продукт. Бэклог, которые тасуется, т. е. стек этих задач, который тасуется в соответствии с приоритетами. Мы поговорим об этом более подробно, когда будем обсуждать артефакты. И достаточно простые практики управления. Команда, по сути дела, — это самоадаптирующаяся система, которая решает свои проблемы. Проблемы не прячутся. За проблемы никого не наказывают. Проблемы открыто высказываются, ну в идеальном, естественно, случае, на этих самых 15 минутных совещаниях ежедневных, которые называются scrum, в случае подхода Scrum. На самом деле, все подходы Agile, так или иначе, подразумевают подобные совещания и итеративную разработку. Команда сама принимает решения, каким образом мы будем, так или иначе, исправлять те проблемы, которые возникли, каким образом мы будем помогать тем сотрудникам, которые испытывают определенные затруднения. Активное участие клиента. Клиент, в отличии от MSF и RUP, здесь является активным игроком в команде. Клиент позволяет более быстро и гибко перетасовать требования, адаптироваться к тем изменениям, которые, возможно, несет бизнес-среда или кризисные ограничения, скажем, по финансам и по времени. Поэтому, как и в Microsoft Solution Framework, у нас здесь достаточно открытое прозрачное общение между всеми членами проектной команды, открытые коммуникации. Очень часто устные коммуникации, что, может быть, и не совсем хорошо, поскольку далеко не все документальные артефакты протоколируются, далеко не все обещания фиксируются на бумаге или даже в электронной почте. Ежедневные собрания — это, по сути дела, team building, укрепление команды. Что касается недостатков, они являются оборотными сторонами достоинств. Это, к сожалению, поскольку у нас нет четких стандартов по артефактам, зачастую архитектурный проект представляется в упрощенном виде. Зачастую требования также представляются в виде, который не соответствует, предположим, стандарту UML или каким-то другим стандартам. И, вообще говоря, четко определенной проектной документации не существует. Поэтому при неумелом руководстве scrum-мастера, процесс разработки может стать во многом анархичным и не предсказуемым. Но с другой стороны, Scrum — это достаточно хорошее средство за счет адаптивности команды решения кризисных проблем.