Agile-документация: баланс между скоростью и сохранением знаний

Различные документы, артефакты и процессы, связанные с их созданием, являются одними из основных символов модели водопада. Заимствуя у Lean, Agile рассматривает большое количество документации как «отходы», от которых необходимо избавиться, чтобы оптимизировать жизненный цикл разработки.

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

Традиционный подход к документации подвергается сомнению

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

Agile фокусируется на том, чтобы добиться цели и повысить ценность для заинтересованных сторон. Она построена таким образом, что модель не поощряет работу с периферией и действиями, которые не приносят прямой и немедленной пользы клиенту.

Документация в Waterfall против Agile

У каждой компании разный уровень документации, который может отличаться даже на уровне проекта. Но вот как выглядят типичные процедуры документирования в проектах Waterfall и Agile:

Дело о документации

Waterfall продвигает гораздо более строгий подход к документации, который может показаться чрезмерным. Но прежде чем мы отвергнем это как «отходы», вот несколько преимуществ наличия строгих процедур документации.

Возможность стратегического мышления

Те, кто не в состоянии планировать, планируют потерпеть неудачу. Документация заставляет менеджера проекта сесть и все обдумать, а затем предложить лучшие решения. Люди иногда неверно истолковывают Agile-ценность работающего программного обеспечения по сравнению с исчерпывающей документацией, считая, что никакой документации не требуется. Затем они устремляются на рынок. Пол Адамс, вице-президент по продукту в Intercom, описывает этот шаг как бросание вещей в стену и поиск того, что прилипнет. Разработка решений, создание планов, обдумывание действий — эти действия создают ценность, экономя время, не прорабатывая каждую идею функции, которая приходит на ум.

UX и функциональная согласованность

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

Документацию можно преобразовать в руководства пользователя

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

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

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

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

Регулярное взаимодействие между продуктовыми командами и участниками Agile-команд

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

Уход и планирование разделяет задачи

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

Пользовательские истории обеспечивают эффективную документацию

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

Снижение потребности в документации кода

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

Agile Церемонии

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

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

Гибридные подходы к документации

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

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

Сочетание UML и Agile

Рассмотрите возможность использования стандартного языка моделирования, такого как Unified Modeling Language (UML), который очень структурирован и имеет определенные объекты для визуализации системы. Это помогает сделать содержание очень простым и сосредоточенным на том, что необходимо, и обеспечивает минимальное использование письменного языка. Такие инструменты, как StarUML и Draw.io, среди многих других, являются удобными вариантами.

Генераторы документации кода

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

Детальный дизайн и UX-документы

Определение требований с использованием каркасов, макетов, пользовательских блок-схем, диаграмм последовательности и т. д. помогает упростить потоки проекта, а также ясно дает понять технической группе, что необходимо разработать. Проектная документация — отличный способ иметь различный уровень жесткой документации. Для этих задач можно выбрать различные инструменты для создания каркасов и UX.

Инструменты управления проектами Автоматизируйте документацию

Более мощные инструменты управления проектами и связанные с ними инструменты, такие как JIRA, Confluence, Asana и Basecamp, позволяют хранить всю информацию, связанную с проектом, в одном месте. Задачи могут быть связаны, помечены, вложены друг в друга и назначены разным членам команды, которые затем могут оставлять комментарии и сообщать о любых проблемах. Все эти действия, наряду с гибкостью адаптации этих инструментов, могут создать значительный объем документации практически без усилий.

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

Управление документацией — это баланс

Создатели Agile Manifesto пишут, что они ценят «рабочее программное обеспечение больше, чем исчерпывающую документацию». Тем не менее, они также добавляют оговорку о том, что «хотя элементы справа имеют ценность, [они] больше ценят элементы слева». Agile не предлагает удалять всю документацию, потому что некоторая документация явно представляет ценность; он просто предполагает, что приоритет должен отдаваться рабочему программному обеспечению и добавлению документации только по мере необходимости в зависимости от обстоятельств проекта и без существенного препятствия прогрессу разработки.

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