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

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

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

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

Зачем создавать и поддерживать документацию?

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

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

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

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

Определите основные аудитории и варианты использования

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

  • Команды разработчиков, активно работающие над микросервисами и приложениями, которым необходимо погрузиться в аспекты систем, созданных другими командами, с которыми они сотрудничают, по зависимостям и выпускам.
  • ИТ-операции, бизнес-операции, информационная безопасность, специалисты по управлению ИТ-услугами и инженеры по надежности сайта, которые хотят понять архитектуру, рабочие процессы, бизнес-логику, данные и условия ошибок
  • Владельцы продуктов, специалисты по пользовательскому опыту, дизайнеры и маркетологи, которые хотят разбираться в картах путешествий, веб-аналитике и моделях использования конечными пользователями.
  • Специалисты по управлению данными, которые хотят проверять данные на предмет безопасности, конфиденциальности и соответствия требованиям.
  • Специалисты по обработке данных, инженеры по работе с данными и распорядители данных, которые хотят обеспечить качество данных, установить основные источники данных и использовать источники данных приложений в моделях последующей аналитики и машинного обучения.
  • К организации присоединяются новые технологи, в том числе разработчики, бизнес-аналитики, инженеры по автоматизации тестирования и инженеры DevOps, которым поручено поддерживать и улучшать код, разработанный их предшественниками.

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

Лучшая практика – определить заинтересованные стороны документации и определить их первоочередные потребности. Agile-команды должны рассмотреть возможность перечисления потребностей в документации в своих журналах и согласовать соглашения. Уместно определить критерии приемки, если ожидается документация с историей пользователя, например создание документации API, когда разработчики ее кодируют. Также может быть полезно установить настраиваемый тип задачи Jira, тип рабочего элемента Azure DevOps или другой тип карточки в невыполненной работе схватки, чтобы обозначить конечный результат документации.

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

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

С тех пор, как я работал техническим директором стартапа и ИТ-директором предприятия, у меня сложилось твердое мнение об инструментах и ​​стандартах. Организации могут использовать Microsoft 365 или Google Workspace для создания документов, презентаций и электронных таблиц и управления ими, но они не являются оптимальными платформами базы знаний для групп гибкой разработки и DevOps. Полезный технический документ часто представляет собой смесь диаграмм, таблиц и хорошо отформатированных документированных разделов. Типичные офисные приложения – не лучший вариант.

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

Я рекомендую ИТ-специалистам и командам DevOps искать инструменты управления знаниями, которые подключаются к их рабочим процессам, обеспечивают богатую информационную архитектуру и создают расходную документацию для всех заинтересованных сторон.

Атласское слияние это инструмент управления знаниями, недавно представленный как Победитель конкурса InfoWorld 2021 «Технология года». Более 60 000 клиентов используют корпоративную вики-страницу Confluence для документации, обмена знаниями и совместной работы с Шаблоны Confluence и интеграции. Команды разработчиков, использующие Jira Software, могут создавать пользовательские представления своих невыполненных работ, используя Макросы Jira и включать диаграммы в вики-страницы с помощью таких инструментов, как Gliffy, Miro, Balsamiq, draw.io или Lucidchart.

Другие инструменты документации и обмена знаниями, популярные среди команд DevOps, включают Microsoft Teams. вики и обмен файлами, Microsoft SharePoint, BMC’s ComAround, ServiceNow Управление знаниями, База знаний ProProfs, и другие инструменты управления знаниями. Некоторые организации также рассматривают инструменты и порталы для совместной работы над документами, ориентированные на обмен знаниями, такие как Кусочек, Иглу, Джайв, LumApps, и Simpplr.

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

Установить стандарты документации и рабочий процесс

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

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

Другой стандарт, который нужно определить, – это когда и кто должен создавать, обновлять и поддерживать документацию. Поскольку команды DevOps стремятся выпускать обновления часто, оставлять устаревшую документацию или задолженность по документации безответственно. Лучшая практика – определить стандарты и ожидания в отношении документации как часть процессов управления выпусками и изменениями.

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

Авторские права © 2021 IDG Communications, Inc.


#Управление #знаниями #для #команд #Agile #DevOps

Source link