Русский /

Блог

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

2015-04-09 19-17-39Вот четыре сценария, когда документирование в Agile упростит и улучшит проект:

  • Если в проекте нет инструмента для управления жизненным циклом (ALM, Application Lifecycle Management) или если ALM имеет недостаточную функциональность и слабые возможности интеграции.
  • Если проект имеет сложную структуру требований.
  • Если проект является долгосрочным.
  • При активном участии в проекте несколько заинтересованных сторон.

 
Наталья Воронько,
менеджер Agile-проектов First Line Software

Отсутствие ALM или ALM со слабой интеграцией

Не все проекты могут себе позволить такие мощные инструменты как TFS или Quality Center. Требования, тесты и дефекты часто хранятся отдельно друг от друга. Разработчики используют доступные, но не связанные между собой ресурсы, или просто таблички Excel. В краткосрочной перспективе такой подход приемлем и оправдан. Но в перспективе проект растет, требования меняются и добавляются, а управление изменениями усложняется в разы. Команде понадобится гораздо больше усилий, чтобы проектные данные и их взаимосвязь были удобными в использовании, наглядными и понятными.

Удачным решением здесь была бы проектная страница в wiki c высокоуровневыми описаниями реализуемой функциональности и ссылками на соответствующие пользовательские истории и письма. За счет этого будет проще ориентироваться в проектных данных, видеть всю картину, и поддерживать целостность и полноту требований. Команда тратит меньше времени на разъяснения требований и поиск деталей. Для команды удобно, когда есть единая точка входа в проект, откуда можно перейти ко всем ключевым процедурам и активам проекта. Улучшая ясность требований, мы повышаем качество продукта.

Проект предполагает взаимодействие с различными участниками проекта

Сегодня к работе над проектом могут быть причастны не только заказчик и команда разработчиков, а гораздо больше заинтересованных сторон. Это могут быть удаленные команды разработчиков, команды из иной бизнес области (например, отдел рекламы, техподдержка и т.д.). Команды могут использовать общий или собственный инструментарий . Но даже если все вовлеченные стороны имеют доступ к, например, проектному репозиторию, это не значит, что все они обладают достаточными техническими навыками, чтобы свободно его использовать.
Целесообразно продумать заранее, какие данные и кем будут востребованы, проанализировать, в каком виде лучше их представить. Например, можно приготовить краткое описание основных принципов реализации проекта, распределения обязанностей. Можно указать, что сделано на вашей стороне, как с этим работать, обязательно указать ответственное контактное лицо (как правило, это скрам мастер/ руководитель проекта, но может быть и другой участник проекта.)

Проект имеет сложную структуру требований

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

Долгосрочный проект

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

Итоги

Продуманная и разумная документация экономит время и уменьшает расходы. Влияние внешних факторов сходит к минимуму. Количество ошибок сокращается. Важно помнить, что в agile документация – это не то, с чего проект начинается. Наоборот: документация часто фиксирует уже готовую функциональность. Организация коллективного использования ценной документации - это обязанность Проектного менеджера/Scrum мастера. Как лидер, PM/SM, должен уметь показать команде, как такой метод помогает в достижении цели и обеспечивать каждому члену команды четкое понимание задачи. А если команда полностью понимает цель, разработка будет спланирована, выполнена и принята заказчиком.