Добрый вечер. Подход docops никогда не ставил целью спихивать что-либо заказчикам или как-то концентрироваться на качестве отдельных документов. Плохой документ может создаваться и ворде, и в конфлюенс и в гите. Суть данного подхода в автоматизации тех практик, которые сейчас практически полностью ручные: 1. Формат документа - простая читаемая разметка; 2. Использование для написания техник аналогичных техникам разработки, 3. Отсутствие необходимости актуализации доков в 100 источниках (конфлюенс хорош, когда он один, а что делать если аналогичная документация развернута у заказчиков, и каждый из них просит тот формат, что ему удобен? На каждом ресурсе каждый из нескольких десятков доков обновлять? Как-то минимально продуктивно), единый процесс доставки, когда заказчик получает новую версию документа с новой версией сервиса, и т.п. В этом суть docs as code.
Гитхаб - это все-таки хостинг для совместной разработки, а у нас она своя. Гит используется как система контроля версий, а все остальное уже сугубо корпоративное.
Дисциплина, в первую очередь, должна обеспечиваться со стороны лидов и РП, если они выстроят процессы, то и банально изменения в интерфейсах и других программных аспектах будут ими отслеживаться с постановкой соответствующих задач писателям и другим заинтересованным лицам. Они же тоже часть команды и их можно привлекать к планированию работ и т.п. митинги, где они опять же смогут фиксировать грядущие изменения и прочие важные моменты.
Что же касается способов следить за изменением кода, то почему не настроить систему так, чтобы она присылала оповещения об изменениях кода и писателям, чтоб они могли своевременно внести изменения в соответствующие блоки документации.
И я опять повторюсь, вопросы актуализации, это в первую очередь, вопросы выстроенных процессов внутри команды, если скинуть необходимость отслеживания изменений на отдельно взятого писателя, который еще и чаще всего не является достаточно компетентным в частных вопросах программирования, ну тогда, скорее всего, да, документация быстро устареет и не будет полезна.
Если же мы применяем соответствующие метрики QA, собираем фидбек и т.п. действия, то актуализация и пополнение документов становятся работой на регулярной основе и позволяют иметь абсолютно достоверную документацию, что уже давно практикуется в различных компаниях с docops - Фолиант в Ростелекоме, xSolla - все живут именно по такой системе, и, вроде бы как, доки у них вполне себе рабочие.
На самом деле, даже те два тезиса, что приведены, - это уже многое. Проведение корректного ревью и возможность совместить процесс передачи кода с передачей документации заказчику - это значительное упрощение работы.
Что же касается актуализации, все-таки это вопрос в большей степени к дисциплине разработки, планированию и выстраиванию процессов. Если документирование, в принципе, отсутствует в планировании работ по новой фиче или обновлению старой, то да, вряд ли мы сможем все отследить вовремя, если же работы запланированы и настроен процесс оповещения группы документирования, то проблем возникать не должно.
Ну, и чисто технически, как понять, что документация сгнила - если она обновлена год назад, а последние обновления запушены вчера, то, скорее всего, она уже никому не нужна. )))
А, в целом, docops скорее способ автоматизировать те процессы обработки и доставки документации, которые мы сейчас выполняем вручную, ну, и приблизить команду писателей к команде разработки.
Добрый вечер. Подход docops никогда не ставил целью спихивать что-либо заказчикам или как-то концентрироваться на качестве отдельных документов. Плохой документ может создаваться и ворде, и в конфлюенс и в гите. Суть данного подхода в автоматизации тех практик, которые сейчас практически полностью ручные: 1. Формат документа - простая читаемая разметка; 2. Использование для написания техник аналогичных техникам разработки, 3. Отсутствие необходимости актуализации доков в 100 источниках (конфлюенс хорош, когда он один, а что делать если аналогичная документация развернута у заказчиков, и каждый из них просит тот формат, что ему удобен? На каждом ресурсе каждый из нескольких десятков доков обновлять? Как-то минимально продуктивно), единый процесс доставки, когда заказчик получает новую версию документа с новой версией сервиса, и т.п. В этом суть docs as code.
Роботы, конечно, хорошо, но как-то странно выглядит команда разработки без иерархии и планирования.
Гитхаб - это все-таки хостинг для совместной разработки, а у нас она своя. Гит используется как система контроля версий, а все остальное уже сугубо корпоративное.
Дисциплина, в первую очередь, должна обеспечиваться со стороны лидов и РП, если они выстроят процессы, то и банально изменения в интерфейсах и других программных аспектах будут ими отслеживаться с постановкой соответствующих задач писателям и другим заинтересованным лицам. Они же тоже часть команды и их можно привлекать к планированию работ и т.п. митинги, где они опять же смогут фиксировать грядущие изменения и прочие важные моменты.
Что же касается способов следить за изменением кода, то почему не настроить систему так, чтобы она присылала оповещения об изменениях кода и писателям, чтоб они могли своевременно внести изменения в соответствующие блоки документации.
И я опять повторюсь, вопросы актуализации, это в первую очередь, вопросы выстроенных процессов внутри команды, если скинуть необходимость отслеживания изменений на отдельно взятого писателя, который еще и чаще всего не является достаточно компетентным в частных вопросах программирования, ну тогда, скорее всего, да, документация быстро устареет и не будет полезна.
Если же мы применяем соответствующие метрики QA, собираем фидбек и т.п. действия, то актуализация и пополнение документов становятся работой на регулярной основе и позволяют иметь абсолютно достоверную документацию, что уже давно практикуется в различных компаниях с docops - Фолиант в Ростелекоме, xSolla - все живут именно по такой системе, и, вроде бы как, доки у них вполне себе рабочие.
На самом деле, даже те два тезиса, что приведены, - это уже многое. Проведение корректного ревью и возможность совместить процесс передачи кода с передачей документации заказчику - это значительное упрощение работы.
Что же касается актуализации, все-таки это вопрос в большей степени к дисциплине разработки, планированию и выстраиванию процессов. Если документирование, в принципе, отсутствует в планировании работ по новой фиче или обновлению старой, то да, вряд ли мы сможем все отследить вовремя, если же работы запланированы и настроен процесс оповещения группы документирования, то проблем возникать не должно.
Ну, и чисто технически, как понять, что документация сгнила - если она обновлена год назад, а последние обновления запушены вчера, то, скорее всего, она уже никому не нужна. )))
А, в целом, docops скорее способ автоматизировать те процессы обработки и доставки документации, которые мы сейчас выполняем вручную, ну, и приблизить команду писателей к команде разработки.