Простору
- Для простору в Confluence
- Структура просторів
- Особистий простір у Confluence
- Календар у Confluence
- Питання у просторах
- Як додати аватар до Confluence
- Як дивитися інформацію про користувача
- Як передплатити користувача
- Створення та редагування статей
- Зміна положення статей у ієрархії простору
- Правила оформлення статей
- Як додавати відео до статей
- Як коментувати статтю
- Як працювати з вкладеннями в Confluence
- Як правильно прикріплювати файли до статей
- Як видалити вкладення
- Надсилання статті іншому співробітнику
- Правила написання статей у FAQ
- Додавання статті до обраного
- Як оформляти вступ до статті
- Як користуватися Подобається (Like) у Confluence
- Робота зі статтями через пошту
- Управління доступом до статті
- Інші дії зі статтею
- Посилання на конкретну частину статті (якір у статті)
- Як шукати коментарі до статей
- Правила пошуку у Confluence
- Як використовувати макроси у статтях
- Макрос Multimedia
- Макрос Відображення дочірніх статей
- Макрос Звіт із завдань
- Макрос додавання витягу зі статті
- Макрос оповіщення групи користувачів
- Макрос відображення контенту по мітці
- Макроси голосування Vote та Survey
- Налаштування повідомлень на пошту з Confluence
- Вікно Повідомлення у Confluence
- Як не потонути в сповіщеннях від Confluence
- Спостереження за статтею та простором
- Як перестати спостерігати за статтею чи простором
- Нагадування відвідати сторінку Confluence
- Як зберігати інформацію про облікові записи
Як ми використовуємо Confluence для розробки вимог до продукту
У статті описано наші підходи до використання Confluence як інструмент для роботи з вимогами до продукту. Не претендуємо на універсальність, але, можливо, ці підходи будуть корисні для вирішення ваших завдань, які не обов'язково пов'язані з процесами розробки вимог (ведення документації користувача, опис внутрішніх регламентів роботи відділу, організація бази знань тощо).
Усі зміни у вимогах до нової фічі на одній сторінці
Ми розробляємо складні Enterprise продукти, які тиражуються для сотень корпоративних замовників. В одному з наших продуктів більше ста функціональних модулів і кожен модуль має окремий документ з вимогами. Фічі нового релізу, як правило, торкаються кількох (від 3 до 20) функціональних модулів.
Щоб зрозуміти всі зміни у вимогах, проектна команда має прочитати всі документи, які зачіпає нова функціональність, до того ж розібратися, що саме змінилося в кожному з них. Це довго та незручно.
Для вирішення проблеми ми зробили зведений документ щодо кожної нової функціональності. Він містить лише зміни вимог до функціональних модулів. При цьому якщо у вихідному документі щось зміниться, це буде автоматично відображено у зведеному документі.
Приблизно так це виглядає у житті:
Тепер проектній команді достатньо прочитати один документ, аби зрозуміти усі зміни.Аналітик один раз «збирає» документ і не турбується, що зміни, що виникають, потрібно підтримувати відразу в двох документах.
Технічно це реалізовано за допомогою плагіна Multi Excerpt, що дозволяє вставляти частини одного документа до різних документів.
У документі з вимогами до функціонального модуля:
Текст частини вимог, що змінилася, обрамляється макросом MultiExcerpt. Якщо зміна невелика (наприклад, змінилася якась одна цифра або невелика пропозиція), ми додаємо в макрос трохи тексту навколо цієї зміни, щоб читач розумів контекст.
На сторінці документа з новою функціональністю:
Додаємо макрос Multiexcerpt include. У ньому вказуємо, який блок із якої сторінки потрібно вставляти:
Готова сторінка фічі в режимі редагування виглядає приблизно так:
Щоб одним поглядом охопити і відразу зрозуміти статус усіх вимог щодо нової функціональності, ми додали до зведеного документа таблицю, що автоматично оновлюється, з переліком пов'язаних вимог, їх статусами, відповідальним аналітиком і коротким описом змін.
Робиться це за допомогою стандартних макросів «Звіт про властивості сторінки» та «Властивості сторінки».
На кожну сторінку з вимогами до функціональних модулів додається мітка (тег) нової функціональності та макрос «Властивості сторінки». У цей макрос додається стандартна таблиця, у рядках якої заповнюються необхідні властивості (на перший погляд здається складно, але в документації все докладно описано).
На сторінку фічі додається макрос «Звіт за властивостями сторінки», в ньому вказується мітка фічі, а також список властивостей, які необхідно відображати.
«Трасування» вимог
Зміни до одного функціонального модуля можуть вимагати змін і в інших модулях.Якщо забути про пов'язані зміни на етапі опрацювання вимог, швидше за все, це стане відомо на пізнішому етапі (наприклад, під час тестування) та вплине на термін здачі релізу. На жаль, у нас були такі прецеденти.
Щоб відстежити вплив функціональних модулів один на одного і не забувати про пов'язані зміни у вимогах, ми використовуємо функціональні можливості міток (тегування). Виходить свого роду трасування вимог, але з великим кроком: лише на рівні функціональних модулів, а чи не атомарних вимог.
При більш ніж сотні функціональних модулів та їх взаємозв'язку навіть такий великий крок трасування дозволив нам значно скоротити кількість випадків, коли аналітик у процесі розробки вимог до нової функціональності забуває врахувати пов'язані вимоги.
Для цього ми використовуємо стандартну функціональність міток у Confluence та макрос «Результати пошуку».
- Знаходимо всі функціональні модулі, на які може вплинути зміни вимог до картки Персони
- Додаємо до них відповідний тег (у нашому випадку це #person)
- Додаємо макрос «Результати пошуку» на сторінці вимог до картки Персони
У режимі редагування виглядає так:
А читач бачить так:
Версіонування вимог щодо релізів
Confluence у парі з плагіном Scroll Versions дозволяє для кожного нового релізу робити окрему гілку вимог, причому у всіх документів у кожному релізі залишається власна історія змін. Переключення між версіями релізів виконується в пару кліків. Крім того, можна порівнювати між собою вимоги різних релізів, так і різних версій одного документа всередині одного релізу.
Так виглядає у житті перемикання між версіями релізів:
Коментування
Для роботи з коментарями ми використовуємо плагін Talk.
- Можна бачити коментарі та відповідати на них у режимі редагування документа. Це дуже зручно, коли треба вносити правки до вимог за результатами ревію
- Немає проблем із паралельним коментуванням (особливо якщо ви плануєте перехід з MS Word + Sharepoint: не потрібно блокувати документ повністю), вимоги може рецензувати одночасно вся проектна команда
- Якщо коментар залишають на сторінці з фічею в блоці Multi Excerpt, він автоматично з'являється у вихідному документі вимог
Від стандартного функціоналу коментування у Confluence ми відмовилися, тому що у нього були критичні для нас мінуси:
- Не можна використовувати у зв'язці з плагіном Multi Excerpt
- Не видно коментарів у режимі редагування документа (UPD: у нових версіях Confluence цей недолік усунули)
- Зникають коментарі, якщо змінити текст, до якого вони були прив'язані
Створення діаграм та мокапів
Спочатку ми використовували MS Visio та експортували схеми в растровий формат, а потім завантажували у Confluence. Такий підхід був незручний — актуальність схем доводиться підтримувати у двох місцях, для цього потрібно багато дій.
Як виявилося, у Confluence є безліч плагінів для роботи з різного роду графічними об'єктами (діаграми, схеми, мокапи та ін.). Balsamiq Wireframes for Confluence та Draw.io Diagrams for Confluence дозволяють редагувати графічні об'єкти, не виходячи з Confluence. Наразі ці плагіни майже повністю покривають наші потреби.
Базові можливості
Коротко розповім про базові можливості, які надає Confluence (як більшість інших вікі-систем). Щоб не переказувати документацію, обмежуся списком того, чим ми переважно користуємося:
- Порівняння версії документів. Можна швидко зрозуміти, як змінювалася функціональність від релізу до релізу.
- Паралельне редагування одного документа та автоматичне вирішення конфліктів. Рев'ю документа можуть робити одночасно кілька людей і при цьому не потрібно чекати своєї черги, поки документ заблоковано на редагування іншим співробітником (як було, коли ми використовували Sharepoint і вимоги зберігалися як Word-файли).
- Шаблони документів. Ми створили шаблони з усіх основних типів документів (функціональний модуль, фіча, протокол наради)
- Гнучкі можливості розмежування доступу (до рівня сторінки). Це зручно, наприклад, для аутсорсних співробітників, яким не можна надавати доступ одразу до всіх вимог
- Експорт документів у різні формати. Дуже рятує у тих поодиноких випадках, коли виникає необхідність передачі документів назовні.
- Інтеграція з JIRA. Можна автоматично вставляти статус завдань, терміни погоджень та іншу інформацію з тикетів JIRA.
Перехід із MS Word
Є кілька неочевидних речей, з якими майже одразу зіштовхуєшся після переходу з Word на Confluence.
Нумерація заголовків
Щоб додати автоматичну нумерацію заголовків, необхідно обрамити текст макросом Numbering headings.
Гіперпосилання на розділ
Щоб усередині документа послатися якусь частину документа чи заголовок розділу, потрібно спочатку додати макроc Anchor (у російської локалізації він називається «Анкер»), та був додати гіперпосилання нього із потрібної частини документа.
Додаємо макрос Anchor та вказуємо його ім'я (Вставити -> Інші макроси -> «Anchor»):
Так він виглядає у документі в режимі редагування:
Потім вставляємо посилання на цей якір у документі (Вставити -> Посилання -> Додатково):
- Для створення посилання на інший документ перед назвою якоря вказуємо назву документа, який потрібно послатися, потім символ «#» і після нього назва якоря.
- Для створення посилання на поточний документ перед назвою якір просто вказуємо символ «#».
В офіційній документації сказано, що посилання на заголовок можна зробити і без макросу Ancor, але тоді посилання втрачатиме працездатність при зміні тексту заголовка.
Колір тексту фону
Зробити нестандартне візуальне оформлення тексту, зокрема виділити тло тексту
заливкою можна за допомогою Markdown-розмітки (Вставити -> Розмітка, Markdown).
Підставте RGB-код потрібного кольору.
Для любителів автоматизації є ще один лайфхак: можна спочатку у візуальному редакторі змінити колір тексту, а потім у режимі редагування вихідного коду сторінки за допомогою регулярних виразів зробити автозаміну HTML-розмітки виділення тексту кольором на заливку.
Це не дуже зручно, але іншого способу виділяти текст заливкою ми поки що не знайшли.
З мінусів:
- Копіювання та вставка з буфера обміну розміченого таким чином тексту зазвичай веде до втрати розмітки.
- Змінити розмітку можна лише у режимі редагування вихідного коду сторінки.
P.S. Стаття заснована на базі доповіді Лайфхакі Confluence для розробки вимог на конференції Analyst Days, відео версію цієї доповіді можна переглянути за цим посиланням.
Автор статті: Ільшат Габдуллін g1r
