Имеет ли термин "документация" право на существование в среде гибкой разработки? Целью гибких проектов является сохранение документации максимально простой, так как они полагаются не на характерные для предприятия детали, а на план-графики, обзоры и концепции. Но что происходит, когда гибкий подход применяется в более сложных проектах? Например, что если пишет программное обеспечение одна группа, а эксплуатировать его будет другая? Или если в дверь постучатся аудиторы? В таких случаях простейшей документации на основе одних лишь пользовательских историй может оказаться недостаточно. В этой статье говорится о том, как группы, работающие со сложными проектами, могут применять гибкий подход к документации.
"Гибкая документация" ― оксюморон?
Во многих группах гибкой разработки слово "документация" считается едва ли не ругательным. Ведь эти группы работают, исходя из предпосылки, что неопределенность настолько распространена и изменения происходят так быстро, что большая часть времени, потраченного на предварительную разработку архитектуры или дизайна, окажется потерянной. Они предпочитают короткие, частые итерации и применяют к архитектуре и дизайну подход рефакторинга.
Если объяснять в двух словах, то, начав с идеи, группы гибкой разработки разбивают ее на особенности и функции, составляют общие требования и принимаются за работу. Их цель ― документировать ровно столько, чтобы приступить к проектированию, составить ряд приоритетных требований в каждой итерации, собрать эти требования в список рабочих элементов и составить документацию, которую каждый сможет использовать в работе с программным обеспечением.
Наличие документов, которые может использовать каждый, ― благородная цель; однако в некоторых случаях документ, предположительно пригодный для всех, на самом деле оказывается не нужен никому. Когда группы гибкой разработки увеличиваются в размерах и оказываются в среде крупной корпорации, им приходится применять более зрелую, но не менее гибкую стратегию разработки документации.
Недостающая сопроводительная документация
Сегодня методы гибкой разработки применяются во многих критически важных проектах, таких как разработка торговых приложений или порталов. В этих проектах, как правило, внешняя группа гибкой разработки создает приложение, которое в течение 12-18 месяцев передается для эксплуатации либо самой нанимающей компании, либо другому стороннему поставщику.
Краткие истории и требования действительно хороши для проектирования, но для текущей эксплуатации их недостаточно. По целому ряду причин в них не содержится информация, необходимая для поддержки приложения.
Когда группа работает над большим проектом, часто происходят изменения, которые могут быть не отражены в документации. В этом случае считается, что программное обеспечение уже выпущено, и начинается следующая итерация. В результате группе эксплуатации приходится работать с устаревшей документацией. К тому же документы гибкой разработки зачастую очень лаконичны и не содержат обзора, часто необходимого группе технического обслуживания.
Недостающая документация для аудиторов
В некоторых отраслях, таких, как финансовые услуги и здравоохранение, существуют внешние правила и положения, которым приложения должны соответствовать. Так как в больших проектах важна прослеживаемость, крупные гибкие команды часто используют инструменты для связывания артефактов в целях отслеживания, но иногда этого недостаточно.
Например, я работал над реализацией большого портала для фармацевтической компании. Это был внутренний портал, содержащий данные по исследованию лекарственных препаратов. В этой ситуации аудиторскому контролю подлежала не только система доступа к данным, но и конструкция самого портала. Хотя мы и связали артефакты между собой, мы были слишком сосредоточены на разработке приложений и веб-сайта, и когда появились ревизоры, документы и необходимая отслеживаемость оказались не в порядке.
Как и в случае эксплуатационной документации, информация, нужная аудиторам, не обязательно отвечает "универсальным" требованиям, предъявляемым к документации. Придания проекту прослеживаемости тоже недостаточно. Аудиторам нужна документация, подтверждающая соответствие нормативным требованиям.
Когда группы гибкой разработки сталкиваются с этими двумя факторами масштабирования ― отдельными группами эксплуатации и требованиями внешней ревизии, ― самое время обратиться к методам Disciplined Agile Delivery и такой практике, как непрерывное документирование. Чтобы заполнить пробел между документацией, составленной для гибких проектов, и потребностями группы эксплуатации и аудиторов, можно применить к выпуску документации такой же подход, что и к выпуску кода. Вместо того чтобы выпускать документацию для всех, которая на самом деле не нужна никому, подумайте о выпуске специальной эксплуатационной документации и документации для аудиторов в рамках отдельных итераций.
В проектах, в которых я работаю, мы создаем отдельные требования, истории и артефакты и получаем отдельные результаты в рамках итераций. Для службы эксплуатации мы строим некоторую структуру, основанную на том, чего хочет группа эксплуатации. Мы анализируем гибкие требования, а затем смотрим, чего недостает. Работа по каждой итерации включает в себя устранение пробелов.
Для аудиторской документации мы собираем все требования и включаем их в историю. На самом деле история не будет полной до тех пор, пока мы не составим отчет и полную матрицу совместимости и не привяжем их к этой истории. Мы признаем, что, возможно, придется добавить дополнительную отслеживаемость, что постоянно появляются новые нормы и правила, а старые развиваются, и мы должны идти в ногу.
Требования, артефакты, эксплуатационная документация и аудиторские документы ― все это может сосуществовать, не обязательно в одном и том же месте, но как часть разных итераций. И облегчению создания документации способствуют подходы just-in-time (точно в срок) и fit-for-purpose (соответствие конкретному назначению), которые предусматривают использование по мере возможности одних и тех же компонентов.
Ведь если посмотреть на руководства по эксплуатации или справочники администратора, то можно заметить, что они содержат некоторые элементы, присутствующие в проектной документации. Отслеживаемость, требуемая аудиторам, отчасти совпадает с тем, чего хотят сами группы гибкого проектирования: связи между бизнес-требованиями, элементами разработки и приемо-сдаточными испытаниями.
В проектах гибкой разработки, в которых я участвую, мы выявляем эти сходства, публикуем оболочку и составляем шаблон со схемой, содержащей выдержку из блок-схемы процесса или архитектурной схемы. В руководство можно включить некоторые объекты, созданные в других инструментах. Результатом этого подхода стало создание "мини-документов". Наши мини-документы для группы эксплуатации оказались даже популярнее старых громоздких конструкторских документов, потому что можно сразу попасть в то место, где обнаружен дефект. И больше не нужно иметь дело с огромными документами, в которых трудно ориентироваться.
Когда проекты становятся масштабными, и появляется отдельная группа эксплуатации или может нагрянуть ревизия, документации приложений, созданных группами гибкой разработки, которая основана на требованиях, артефактах и историях, может оказаться недостаточно. Если же применить гибкий подход к самому процессу масштабирования, то можно выпустить документациу, подходящую для разных целей. В ходе работы определите требования к документации, включите в свои итерации составление различных версий документов, и вы получите нужную документацию для всех заинтересованных сторон, включая группу эксплуатации и аудиторов.