Всё для технического документирования
+7 (925) 328-76-00
Разработка технической документации
Курсы для технических писателей
Программное обеспечение

Адвокат пользователя: теория хаоса и практика — писатели и пользователи в эджайле

01.03.2017

Эджайл – беда или благо для технического писателя? Попробуем разобраться вместе с Филом Девисом, опытным техническим писателем из компании Integral Development Corp., США.


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

  • Скрам: Мир просто сочится заряженным тестостероном действием, мускулистыми потными членами команды, запертыми вместе и выступающими друг против друга. Как здесь найти место писателю? Я мяч, который топчут и выпинывают на газон?
  • Лин: Нет спецификаций? Я должен опираться на ежедневные митиниги, обсуждения лицом к лицу, потоки электронных писем, доски с задачами и систему отслеживания проблем? И я должен использовать эти источники для написания документации для продукта, который я, скорее всего не вижу или не использую?
  • Спринт: Я погружаюсь в скрам, спеша создать соответствующую документацию каждые две-четыре недели? Без спецификации? Или продукта? В то же время участвовать в ежедневных митингах по каждому скраму?

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

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

К настоящему моменту я проработал в гибридном эджайл-окружении около шести лет. Я всё ещё (в целом) в здравом уме. Обратная связь от коллег и клиентов показывает, что я всё ещё продуктивен. Я могу сказать без оговорок и ограничений, что счастлив. Почему я счастлив? Я получил некоторый опыт дружественных писателю аспектов эджайла, разработал несколько адаптационных стратегий для не столь дружественных аспектов, и я видел некоторые преимущества, которые эджайл может принести пользователям. Думаю, что эджайл помогает мне быть лучшим адвокатом пользователя.

Писатели в эджайле

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

Маленькие вещи

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

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

Большие вещи

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

Приоритеты

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

Меньше мусора

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

Преимущества для пользователей

Я выделил некоторые функции эджайла и свою реакцию на них с точки зрения писателя, но что насчёт пользователей? Что пользователь получает от эджайла и получает ли вообще?

Свежий контент

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

Лучший контент

Эджайл может также улучшить качество этих частых обновлений.

Будучи заметным членом нескольких скрамов, я постоянно разговариваю с разработчиками и владельцами продуктов. Ответом на 90% моих вопросов является короткое обсуждение или короткий мобилизующий митинг. У моих коллег нет старой, несвежей спецификации, за которой можно спрятаться. Они не чувствуют необходимости прятаться от меня, потому что наше взаимодействие быстрое и безболезненное. У меня тоже нет старой, несвежей спецификации, за которую можно зацепиться и которая может дать мне ложное чувство безопасности. Я трачу куда меньше времени, отвечая на вопросы типа «Откуда ты это взял? Это полностью неверно/старое/устарело». Хотя я раньше находил оправдание в ответе «из спецификации», я не получал от этого удовлетворения. Это не было продуктивно. Я против создания напряжения и неприязни в отношениях. Я за создание правильной документации.

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

Ввод пользователя

Процитируем ещё один элемент Манифеста эджайла: «мы стремимся поднять ценность совместной работы с клиентами над обсуждением условий контрактов». В теории у клиентов есть формальная и активная роль в разработке. На практике уровень вовлечения может разниться под влиянием нескольких факторов, не только степени открытости для них в плане совместной работы и как они воспринимаются. Когда у меня есть дружелюбный, мотивированный клиент, по моему опыту, эджайл действует лучше всего. Я получаю конструктивную и своевременную обратную связь от клиента во время написания документации, и я знаю, что все мои пользователи будут вознаграждены опытом клиентов, воплощённым в документации.

Эджайл не является «серебряной пулей». Он также не является монстром, который изолирует и поглощает несчастных писателей. Это просто методология разработки со своим набором вызовов и преимуществ. Я прихожу к интерпретации определения ценности «рабочего программного обеспечения» Манифеста эджайла через «всеобъемлющее документирование» не как угрозу, как как ограничитель. Цель разработки продукта не в том, чтобы написать детальные спецификации и пухлые справочные руководства, а в поставке продукта, который даёт возможность пользователю достичь успеха. Документация всё ещё играет ключевую роль в сохранении счастья и успеха пользователя.

В целом, мой опыт в эджайле привёл меня к собственной модификации Манифеста: «Я должен стремиться к повышению ценности рабочей документации через всеобъемлющее документирование».

Источник: Users’ Advocate: Chaos Theory and Practice — Writers and Users in Agile

Тэги: , , , ,

< Вернуться к списку публикаций

Облако тегов