Совместная приоритезация требований
Совместная работа членов проектной команды является ключевой ценностью процесса гибкой разработки и наравне с выявлением уровня зрелости требований и практикой визуализации требований, позволяет выстроить процесс приоритезации требований в Agile проекте. Совместная работа способствует развитию общего и неявного знания; она стимулирует ход общения, переговоров и соглашения во многих аспектах. В гибкой разработке, при условии своей итеративности, церемонии являются важным средством стимулирования коллективной работы. Например, в Scrum такие события, как ежедневные встречи, планирование спринта, обзор и ретроспектива являются такими примерами. Церемонии также приносят пользу членам команды, поскольку они привыкают к определенному ритму церемонии. Например, если обзор итогов проходит каждую вторую неделю в четверг после обеда, то каждый член команды блокирует эту дату в своем рабочем графике и подготавливается к следующей встрече. Мы также рекомендуем включать процесс пересмотра баклога, связанного с отображенными на доске визуализированными требованиями, в набор церемоний. Эти мероприятия, как правило, относятся к более среднесрочной перспективе, т.е. проходят в рамках плана разработки с временным горизонтом, следующим за очередным спринтом (итерацией) и вплоть до следующих 6-12 спринтов. Наблюдения, сделанные во время выполнения проектов, показывают, что команды используют ценные визуализации требований на уровне эпика (фичи), т.е. на уровне, находящемся над пользовательскими историями. Подобные визуализации используются для создания пользовательских историй. Как правило, такие эпики не добавляются на верхний уровень бэклога, тем не менее, они корректируются и проходят через декомпозицию в процессе трансформирования в пользовательские истории. Преимуществом такой визуализации является то, что у команды сохраняется репрезентация эпика и после его разбивки на меньшие элементы в рамках одного бэклога. Это представление эпика используется для управления разработкой соответствующих пользовательских историй, создания критерия приемлемости для атрибутов функциональности и качества; и для принятия единого согласованного решения по уровню комфорта, для которого разработан эпик, тем самым избегая украшательства требований. В процессе разработки требований, начиная от тем, переходя к эпикам и заканчивая пользовательскими историями, команды работают с визуальной репрезентацией следующим образом:
Мы рекомендуем создавать визуализации только для важных требований. Примерный список вопросов для определения важности может выглядеть следующим образом:
Основываясь на этот список, мы бы порекомендовали визуализацию для требования с высокой относительной ценностью для бизнеса, которая представляет взаимодействие пользователя и находится в строгом соответствии со стратегическим планом разработки. Мы советуем проводить такое обсуждение в тот момент, когда требование изменяет уровень зрелости на определенный и согласованный статус. Например, как только команда договаривается, что уровень зрелости эпика переходит от облака к дереву, она принимает решение по поводу необходимости создания визуализации. Следующей стадией зрелости команды может быть формулировка командой “определения готовности” для эпика, находящегося на уровне зрелости “дерево”. Последующее принятие решения о визуализации является входом в это “определение готовности уровня зрелости дерево”. После этого шага мы как минимум будем знать, какие из имеющихся эпиков являются важными. В идеале должен быть один эпик, но, как правило, это набор эпиков с равнозначной степенью важности. В этом случае, руководствуясь интересами заинтересованного лица и владельца продукта, команда обязана принять решение по поводу более проработанного приоритета требований. -- Автор: Rainer Grau http://re-magazine.ireb.org/issues/2014-1-learning-to-fly/innovation-arena/ |
Еще интересные статьи на эту тему:
|
