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

Я хочу рассказать о еще одном способе контроля за результатами проекта и качеством создаваемого продукта, который в полной мере реализуется в системе управления проектами DEVPROM. Для краткости назову этот метод "Управление проектом через артефакты".

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

Таким образом, метод управления проектом через артефакты является ортогональным, то есть независимым (или дополнительным) по отношению к классическому анализу плана проекта. Посмотрите на следующее изображение, где отражено состояние журнала продукта в разрезе подготовленных артефактов (в терминах DEVPROM это называется трассировкой):

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

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

С точки зрения идентификации рисков, связанных с успешным выпуском очередного релиза продукта, трассировка позволяет увидеть много "подводных камней" текущего релиза:

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

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

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

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

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

Измерение прогресса по выполненным пожеланиям

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

Характерно то, что матрица трассируемости активно используется на этапе анализа, но незаслуженно забыта на остальных фазах, а ведь там она не менее актуальна и позволяет контролировать покрытие различных артефактов разработки друг другом, например, покрытие тестировочной документацией разделов требований. Матрица трассировки - это лишь инструмент, который помогает вашей команде чувствовать контроль над ходом проекта. Можете его не использовать, если все связи вам удобнее хранить в голове и там же актуализировать все связи по сотням документов :)

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

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

Таким образом, использование матрицы трассировки на всем объеме подготавливаемых артефактов, позволяет достичь вашей команде следующих целей:

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

Возможности по связыванию различных артефактов и их трассировке вы найдете во многих ALM решениях (Polarion, TFS), однако, в DEVPROM есть и ряд существенных преимуществ:

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

Mike Cohn в одной из своих презентаций, Введение в оценку и планирование Agile проектов (.pdf) приводит неожиданные результаты исследований по качеству оценки проектов.

Так, даже казалось бы самые незначительные факторы, способны очень сильно повлиять на оценку проекта.

Например, детали спецификации, от которых оценка явно не зависит :

• Группе А дали на оценку спецификацию, оценка оказалась равна 20 часам
• Группе В дали на оценку точно такую же спецификацию, но добавили в нее несколько не влияющих на оценку подробностей - оценка оказалась в 39 часов (это увеличение в два раза!).

Или другой эксперимент, в котором изменялся размер документа спецификаци и:

• Группе А дали спефицикацию длиной в пару страниц - оценка составила 117 часов
• Группе В дали спецификацию с точно таким же текстом, но отформатированную иначе: большее междстрочное расстояние, увеличенный шрифт и т.п. - итого 7 страниц. Оценка в данном случае составила уже 173 часа (!).

Или вот еще отличный пример с давлением ограничениями :

• Группе А дали спецификацию на продукт, оценка составила 456 часов
• Группе В дали точно такую же спецификацию, но сказали, что заказчик расчитывает на 500 часов - в итоге получили оценку в 555 часов
• Группе С дали точно такую же спецификацию, но сказали, что заказчик расчитывает на 50 часов - в итоге получили оценку всего в 99 часов (!)

Конечно, это всего лишь результаты чьих-то экспериментов, которые в некоторых случаях можно и оспорить, но!

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

Но можно ведь как-то повысить точность оценки, не прибегая к формальным методикам?

Конечно можно, вот лишь пара хороших практик:

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