Мне поручили переписать все руководство пользователя, которое не обновлялось годами в компании, и я единственный технический писатель в команде. Все эти годы рассылались только примечания к выпуску. Компания использует гибкий процесс разработки, и спринт обычно длится три недели.
Я думал, как мне подойти к этой задаче. Должен ли я писать руководство, используя то, что было в системе на момент написания, а затем, когда все разделы будут готовы, включить то, что было упущено в примечаниях к выпуску? Или я должен сначала писать разделы, связанные с спринтами, а затем работать над другими разделами, когда я свободен? Есть ли другие лучшие подходы?
Я писал руководства по процессу Scrum, поэтому опишу, что сработало для моей команды.
Я буду относиться к вашей задаче так, как будто вы пишете новую книгу. Судя по вашему описанию, вы в любом случае замените подавляющее большинство контента, поэтому лучше думать об этом как о новой книге (для которой вы могли бы воспользоваться случайным ранее написанным фрагментом), а не как об обновлении.
Сначала вам нужно будет придумать набросок или общий план атаки. Какие темы вам нужно осветить (как подробно)? Возможна ли теперь организация оригинальной книги или вам нужно что-то переделать? В (или до!) вашего первого спринта составьте первоначальный список работ, которые необходимо выполнить. Начните думать о том, как это разбивается на истории. (Это первоначальный отставание; вы должны ожидать, что обнаружите больше вещей, которые необходимо будет охватить по мере продвижения спринтов. Используйте свой обычный процесс для управления ими; в нашем случае недавно обнаруженные проблемы были добавлены в отставание и учтены при следующем планировании. сеанс.)
Во время планирования спринта вы (во множественном числе) должны определить, над какими из этих задач нужно работать сейчас — из-за срочности, стабильности кода или любых других критериев, действующих в вашей команде.
Во время каждого спринта вы должны работать над следующими типами задач:
Написание нового материала (в объеме, соответствующем спринту, за вычетом другой работы, которую вам нужно выполнить в этом спринте)
Рассмотрение отзывов о том, что вы написали в прошлом спринте (вы должны получать отзывы от разработчиков, тестировщиков и представителей пользователей по мере продвижения)
Обновление предыдущей работы для изменений в коде, если это применимо — если вы работаете над документом вместе с разработчиками, работающими над кодом, вероятно, будут изменения, которые вам нужно будет устранить.
Во время последних нескольких спринтов перед релизом начните думать о том, что нужно будет включить в примечания к релизу. Я предполагаю, что примечания к выпуску — это командный проект, поскольку они обычно включают такие вещи, как список ошибок от QA. Ваша часть этого состоит в том, чтобы определить, что достаточно важно, чтобы задокументировать то, что не войдет в руководство пользователя, а затем выяснить, как отразить это в примечаниях к выпуску. В результате должна получиться история для вашего последнего спринта, в которой команда согласует задачи, которые будут включены.
(Должен упомянуть, что в моей последней agile-команде примечания к выпуску на самом деле велись командой QA, а не техническими писателями, поэтому мой совет по этому вопросу основан на том, что я видел/слышал от других, а не на личном опыте. опыт.)
СФ.
Прощай, биржа стека
Джеймс
Джаспер