Гибкая разработка пользовательской документации
•
2 likes•881 views
Презентация доклада "Гибкая разработка пользовательской документации" Сергея Рогачева на конференции ALM Summit Russia в Москве 6 февраля 2014 года (http://bit.ly/MrkHSD). См. подробнее в заметке "Отчет об участии в ALM Summit Russia 2014" (http://wp.me/p1650o-eY) в персональном блоге Рогачева Сергея.
Гибкая разработка пользовательской документации
- 4. Накопление долга Актуализация и тестирование Планирование и отслеживание Когда там программисты уже разродятся новой функциональностью? Изменили одну функцию полгода назад – где в документации и что нужно изменить? Где тот программист? Почему все проблемы с документацией всплывают прямо перед выпуском? Эй, хватит меня заваливать работой! А как тестировать? Опять откладываем выпуск из-за документации!
- 6. Что делать? © Н. Г. Чернышевский
- 7. Итеративность Трассируемость Работа делается сразу малыми порциями и не откладывается на потом Легко актуализировать и тестировать Легко планировать и отслеживать Становится возможной автоматизация сборки
- 8. Definition of Done Task Board Определить критерии готовности – это требования к процессу Визуализировать работы – это гарантии выполнения требований к процессу
- 12. Document Item Build Automation Декомпозировать документацию – это не монолитный артефакт, а сборка документаций отдельных пользовательских историй Автоматизировать сборку документации Нам удалось это на Microsoft Team Foundation Server, Microsoft Word и TeamSolutions TeamSpec
- 16. TFS Набор атомарных описаний реализованных пользовательских историй – Document Items Word + TeamSpec Сборка пользовательской документации (черновик документа), включающий Document Items, форматирование и структурирование – Wordфайл Дистрибутив Пользовательская документация, включенная в комплект поставки продукта – XPS-файл
- 17. Какие изменения в документации и команде?
Editor's Notes
- Мы начинали как кроссфункциональная команда, которую я собрал из равных по компетенциям разработчиков. 2 года назад нас было 5, теперь команда выросла до 8 человек. А, кстати, коллеги, кто как понимает понятие кроссфункциональной команды?А вот, как это описывает Хенрик Книберг в книге «Scrum и Kanban: выжимаем максимум»: «команда обладает всеми навыками, необходимыми для успешного выполнения всех задач» – то есть в некотором недостижимом идеале каждый член команды умеет делать все.Выделенного технического писателя у нас не было.Поэтому роль технического писателя вначале выполнял я, менеджер, пока команда не приобрела все навыки, необходимые для успешного создания пользовательской документации. Ровно об этом я и расскажу далее.
- В итоге, к чему мы пришли?В кроссфункциональной команде у нас есть выделенный системный аналитик, который также выполняет функции технического писателя. Но при этом практически любой член команды способен и хотя бы раз уже выполнял работу по документированию.А менеджер полностью избавлен от необходимости администрировать процесс – все работает само.