Скрам

К сожалению для MegaFund, компания не определила практики, позволяющие в важном проекте c жесткими сроками автоматизировать нечеткие требования к передовым и непроверенным технологиям, как это описано в восьмой главе. Когда MegaFund начала использовать скрам в этом проекте, он буксовал уже более девяти месяцев, а участники команды безуспешно пытались преодолеть процессуальные и бюрократические препоны, которые CMM третьего уровня наложил на деятельность в неопределенных и непредвиденных обстоятельствах. Я получил неблагоприятное впечатление от CMM в этом проекте и других компаниях. Однако меня все чаще спрашивали, что я думал о CMM и как эта модель связана со скрамом. Поняв, что мне нужны дополнительные информация и знания, я организовал встречу с Марком Полком в Институте программной инженерии осенью 2002 года.

Институт программной инженерии, CMM и скрам

О скраме Марк только слышал, зато был знаком с экстремальным программированием – еще одним аджайловым процессом, подобным скраму, но сконцентрированным больше на инженерии ПО, чем на управлении. В течение первого дня Марк учил меня CMM, а я учил его скраму. Признаюсь, я был очень удивлен и впечатлен CMM. Марк отметил, что это всего лишь фреймворк, описывающий зрелость компании по разработке программного обеспечения. Каким образом добиваться соответствия критериям уровней зрелости – выбор самой организации. Оценщики CMM должны были определить, адекватен ли способ удовлетворения критериев. И тут меня озарило: до 2001 года почти каждая компания использовала предопределенные процессы разработки ПО, поэтому естественно, что фреймворк CMM содержал жесткие предписывающие методы. У них были те же слабые стороны, что и у всех предопределенных подходов, – они работают только в ситуациях, предусмотренных их создателями. Поскольку разработка программного обеспечения является очень комплексным процессом, нашлось очень немного реальных проектов, к которым эти подходы были бы применимы.

Затем Марк перешел к ключевым процессным областям (КПО) разных уровней. Мы оценили, к каким уровням и областям относится скрам. Марк был приятно удивлен: несмотря на то что скрам основан не на предопределенном, а на эмпирическом процессе, использующая его организация будет удовлетворять всем КПО второго уровня и многим КПО третьего уровня, за исключением тех, которые касались стандартизации подходов. Эти КПО были удовлетворены в 2003 году, когда фреймворк скрам, программа обучения Certified Scrum Program и процедура запуска скрам-проекта Project Quickstart были предложены в виде продуктов. На рис. 1 показаны степени от нулевой до второй, в которых скрам соответствует различным КПО второго и третьего уровней. Двойная галочка означает полное соответствие, а одна галочка – в большей части соответствие.

Для демонстрации того, как практики скрама реализуют одну из КПО, давайте взглянем на КПО второго уровня «Управление требованиями». Определение этой КПО: «Цель управления требованиями – добиться единого понимания требований клиента и проектом разработки программного обеспечения и самим клиентом». Скрам удовлетворяет этой КПО с помощью механизма, называемого бэклогом продукта, – открытого, прозрачного и доступного для всех списка поддерживаемых клиентами функциональных и нефункциональных требований, которые используются для управления разработкой спринт за спринтом. Эмергентный характер бэклога продукта позволяет сфокусироваться на элементах с наивысшим порядком. Это позволяет максимизировать вероятность того, что время и силы, инвестированные в детализацию требований, принесут ценность. Менее приоритетные элементы бэклога продукта могут навсегда остаться нереализованными и поэтому игнорируются до тех пор, пока не достигнут вершины списка бэклога продукта.

Эта КПО часто интерпретируется как необходимость поддерживать трассировку требований, чтобы иметь возможность показать, как эти требования реализуются в поставляемой системе. Скрам достигает этой цели путем демонстрации в конце каждого спринта (длительность спринта не более одного месяца). В ходе демонстрации, являющейся частью обзора спринта, клиенты могут увидеть, в какую рабочую бизнес-функцию был превращен каждый взятый в спринт элемент бэклога продукта. С каждой принятой клиентом завершенной функцией бэклог продукта уменьшается на соответствующий ей элемент.

Такой эмпирический подход к трассировке пользовательских требований полностью соответствует критериям КПО, он не создает дополнительную нагрузку на процесс разработки или детальность документации. Он также обеспечивает полную гибкость в управлении и отслеживании изменений требований в любое время на протяжении всего проекта. Остальным процессным областям второго и третьего уровней скрам удовлетворяет аналогичным образом: эмпирически, с минимальной документацией и минимальными дополнительными усилиями.