В зависимости от типа разрабатываемого приложения и взаимоотношений с заказчиком, при старте проекта, вашей команде необходимо определиться и договориться о процессе анализа, сбора и управления требованиями. Для одних ситуаций вполне подойдет легковесный подход, реализуемый через истории пользователей.

Перед проектированием очередного приложения или сервиса вам необходимо определиться с его архитектурным стилем, который должен соответствовать основным вариантам использования, ограничениям и нефункциональным требованиям. В мировой практике накопилась неплохая классификация, которую я хочу здесь привести. Под архитектурным стилем будем понимать некоторое высокоуровневое представление о крупных компонентах приложения или системы и взаимосвязях между ними. Цель идентификации архитектурного стиля - дать представление об общей организации и принципах работы приложения, а также реализация основных нефункциональных требований.

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

Не последней функцией любого инструмента для управления проектом является обеспечение измеряемости работы команды и каждого ее участника в отдельности. Например, часто используют концепцию "процент завершения", которая реализуется в подавляющем большинстве инструментов. Задавались ли вы вопросом как "процент завершения" связан с достижением целей проекта?

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

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

Оценить объем программистских работ и измерить его в чем-то кроме часов сложно, а вычислять оставшийся процент трудоемкости еще сложнее. Можно измерять строчками кода, но как известно, генерация кода - это не главная цель, нужно, чтобы конечный продукт получился таким как требуется. В итоге, сегодня вам говорят задача выполнена на 50%, а через два дня вы слышите эту же самую оценку. Работает? Очевидно, что нет. В DEVPROM мы не используем "процент завершения", а вместо этого просим исполнителей записать потраченное время (или добавить к нему потраченное сегодня) и оставшееся время. То есть участники команд оперируют только временем: оценивают работу в часах, устанавливают планируемое время в часах, отчитываются о затраченном и оставшемся времени в часах. Система сама вычисляет необходимые показатели, такие как процент выполнения и представляет их в форме burndown диаграммы.

Таким образом, DEVPROM оперирует следующими параметрами задачи:

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

Рекомендую руководителям проектов, использующим Agile практики и методологии, и архитекторам приложений посмотреть на выступление Ребеки Парсонс (CTO at ThougthWorks) и Мартина Фаулера.