Проектная документация в Scrum

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

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

Например, представьте, что вы находитесь на уроке всемирной истории. Вы начинаете изучать тему “история Западной Европы”. Ваш преподаватель говорит: «Я хочу, чтобы каждый из вас купил мою новую книгу – История Западной Европы: 30-й век». Приготовьтесь к тестированию по первым пяти главам за две недели.

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

Что необходимо документировать в Scrum

Некоторые часто встречающиеся элементы документации включают в себя следующее:

• Руководство для конечного пользователя;
• Руководство по эксплуатации;
• Руководство по устранению неполадок;
• Руководство по выпуску и обновлению;
• Пользовательские истории и детали;
• Модульные тесты;
• Сетевая диаграмма архитектуры;
• Диаграмма архитектуры базы данных;
• Схема архитектуры системы;
• Приемочные контрольные примеры;
• Руководство по разработке API;
• UML (Unified Modeling Language) диаграммы.

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

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

Как преуспеть в проектной документации

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

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

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

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