Большинство команд, использующих физическую доску задач на стене, все равно дублируют задачи в электронном виде в каком-либо трекере. Это может быть обусловленно как географической распределенностью команды, так и необходимостью списывать затраченное по задачам время для отчетности руководству, для сбора статистики, для каких-то других задач - в любом случае, хочется уметь работать и с электронной версией доски задач.
Каждый участник команды обладает своим пониманием жизненного цикла разработки ПО, владеет близкой ему терминологией, опытом ведения проектов, уровнем владения той или иной дисциплиной, полученными в прошлом. У каждого участника есть специфичный опыт работы с различными инструментами...
В классическом Скрам, (таком, о котором говорят его создатели), не найти ни спецификаций, ни описания вариантов использования (use cases), ни, тем более, документов с пугающим словом ТЗ. Вся работа по проекту построена вокруг небольших по размеру, понятных каждому участнику проекта пожеланий, которые легко оцениваются, легко обсуждаются с заказчиком и которые можно реализовать в рамках короткой итерации продолжительностью одну-две недели.
Группы проектов предназначены для объединения нескольких проектов по некоторому признаку. Например, для организации портфелей проектов относительно заказчика или продуктовой линейки. Основное назначение группировки - упростить просмотр различных отчетов по проектам, например, с целью балансировки ресурсов, самого по%D
Любой процесс, связанный с разработкой ПО, делится на этапы, в каждом из которых обозначаются цели этапа, полезные результаты (deliverables), задачи по получению этих результатов, распределение зон ответственности между типовыми ролями участников процесса. Рассмотрим для примера стадии двух известных процессов, отличающихся по структуре:
Командный аутсорсинг разработки ПО
