Классический проект
В классическом проекте мы собираем требования с заказчика, конечных пользователей и других заинтересованных сторон. Требования согласуются, устраняются противоречия между ними и, в конечном итоге, «замораживаются». Такой утвержденный набор требований называется содержанием продукта. Все, что не вошло в содержание, в проекте делаться не будет. Отброшенные требования называются исключениями.
Команда проекта преобразует содержание продукта в набор задач, который чаще всего оформляется в виде иерархической структуры работ (далее — ИСР). На основе ИСР делаются все расчеты — сроков, потребности в ресурсах и деньгах. Для расчетов используется специальные методы — построение сетевой диаграммы, метод критического пути. Так рождается проектный треугольник — удобная метафора, с помощью которой показывается взаимосвязь между работами проекта, сроками и потребностью в деньгах.
Аджайл-проект
В аджайл-проекте уровень неопределенности насколько высок, что мы не пытаемся определить весь состав задач от начала до завершения проекта. Вместо этого команда проекта работает с списком требований (такой список называется бэклогом продукта). Причем, в отличие от классического проекта, бэклог не «замораживается» — он постоянно пересматривается и пополняется.
Требования могут изменяться на протяжении всего проекта, поэтому их превращение в задачи происходит только при планировании ближайшего этапа (в аджайл это итерация, спринт). В аджайл-проекте могут использоваться итерации фиксированной длины, например, 2 недели. Итерация, в этом смысле напоминает классический мини-проект — команда фиксирует объем работы, срок и состав команды, а значит, и стоимость. Получается тот же проектный треугольник, только на итерацию, а не на весь проект.
Если нужно оценить продолжительность всего проекта, команда оценивает сами требования, а не задачи, которые нужны для их выполнения. При фиксированной длине итерации, команда оценивает темп своей работы — сколько требований она сможет сделать за выбранный период времени. Зная общим объем требований проекта и скорость своей работы, легко получается длительность проекта.
Пример. Пусть длина итерации = 2 недели. Команда оценила, что за итерацию сможет сделать требований на 100 человеко-часов. Если общий объем требований составляет 1000 человеко-часов, тогда длительность проекта составит 10 итераций (1000 / 100), или 20 недель.
Такие методы расчета сроков, как построение сетевой диаграммы и метод критического пути в аджайл-проекте не используются.
Основные отличия
Подведем итог. В классическом проекте команда работает со списком задач. Список задач определяет сроки и стоимость проекта — все это фиксируется в виде базовых планов, относительно которых проект контролируется.
Для разных продуктов списки задач могут в значительной степени совпадать, т.к. состав работ определяется технологией производства продукта. Нюансы создаваемого продукта могут на уровне списка задач не проявиться.
Например, в списке задач может быть «Разработать экранную форму для ввода номер телефона». Но для мобильного приложения и для корпоративного портала эта задача подразумевает разный объем работы, разные компетенции людей и разные риски.
Существуют прикладные стандарты, которые содержат такие типовые списки задач. Например, у Института управления проектами (PMI, США) есть стандарт Practice Standard for Work Breakdown Structures. В нем можно найти иерархические структуры работ для нефтегазовых проектов, для проектов внедрения крупных информационных систем и многих других.
В аджайл-проекте фокус внимания у команды на списке требований. Требования уникальны для каждого продукта, в отличие от списка задач. Требования оцениваются по уровню сложности непосредственно без превращения их в список задач. А затем, исходя из темпа разработки команды, определяется и срок проекта и его бюджет.
Таким образом, самая главная отличительная особенность в объекте внимания проектной команды. В классическом проекте — на списке задач, который зачастую может быть типовым, а в аджайл-проекте — на списке требований, которые всегда уникальны.
