Bagaimana kami menggunakan Confluence untuk mengembangkan persyaratan produk

Artikel ini menguraikan pendekatan kami untuk menggunakan Confluence sebagai alat persyaratan produk. Kami tidak berpura-pura bersifat universal, tetapi mungkin pendekatan ini akan berguna untuk menyelesaikan tugas Anda yang tidak selalu terkait dengan proses pengembangan persyaratan (memelihara dokumentasi pengguna, menjelaskan peraturan internal departemen, mengatur basis pengetahuan, dll.).

Semua perubahan persyaratan untuk fitur baru di satu halaman

Kami mengembangkan produk Enterprise yang kompleks yang direplikasi ke ratusan pelanggan korporat. Salah satu produk kami memiliki lebih dari 100 modul fungsional dan setiap modul memiliki dokumen persyaratan terpisah. Fitur dari rilis baru, sebagai suatu peraturan, mempengaruhi beberapa (dari 3 sampai 20) modul fungsional.







Untuk memahami semua perubahan dalam persyaratan, tim proyek harus membaca semua dokumen yang memengaruhi fungsionalitas baru, dan sebagai tambahan, mencari tahu apa yang sebenarnya berubah di masing-masing dokumen. Itu panjang dan tidak nyaman.



Untuk mengatasi masalah tersebut, kami membuat dokumen ringkasan untuk setiap fungsionalitas baru. Ini hanya berisi bagian-bagian yang diubah dari persyaratan modul fungsional. Pada saat yang sama, jika ada perubahan pada dokumen asli, ini akan secara otomatis tercermin dalam dokumen ringkasan.







Sesuatu seperti ini dalam kehidupan nyata:







Sekarang tim proyek hanya perlu membaca satu dokumen untuk memahami semua perubahan. Analis, sebaliknya, "mengumpulkan" dokumen sekali dan tidak khawatir bahwa perubahan yang muncul harus didukung dalam dua dokumen sekaligus.



Secara teknis, ini diimplementasikan menggunakan plugin Multi Excerpt , yang memungkinkan Anda memasukkan bagian dari dokumen yang sama ke dalam dokumen yang berbeda.





Untuk memahami dan segera memahami status semua persyaratan untuk fungsionalitas baru dengan cepat, kami telah menambahkan tabel yang diperbarui secara otomatis ke dokumen ringkasan dengan daftar persyaratan terkait, statusnya, analis yang bertanggung jawab, dan deskripsi singkat tentang perubahan tersebut.







Ini dilakukan dengan menggunakan makro standar "Laporan Properti Halaman" dan "Properti Halaman".

Persyaratan pelacakan

Perubahan persyaratan untuk satu modul fungsional mungkin memerlukan perubahan pada modul lain. Jika Anda lupa tentang perubahan terkait selama tahap pengembangan persyaratan, kemungkinan besar hal itu akan diketahui di tahap selanjutnya (misalnya, selama pengujian) dan akan memengaruhi garis waktu rilis. Sayangnya, kami memiliki preseden seperti itu.



Untuk melacak dampak modul fungsional satu sama lain dan tidak melupakan perubahan terkait dalam persyaratan, kami menggunakan fungsionalitas tag (penandaan). Ternyata semacam penelusuran persyaratan, tetapi dengan langkah besar: pada tingkat modul fungsional, dan bukan persyaratan atom.







Dengan lebih dari seratus modul fungsional dan interkoneksinya, bahkan langkah penelusuran yang begitu besar memungkinkan kami untuk secara signifikan mengurangi jumlah kasus ketika seorang analis dalam proses mengembangkan persyaratan untuk fungsionalitas baru lupa mempertimbangkan persyaratan terkait.



Untuk melakukan ini, kami menggunakan fungsi penandaan Confluence standar dan makro Hasil Pencarian.

Persyaratan versi berdasarkan rilis

Confluence yang dipasangkan dengan plugin Versi Gulir memungkinkan Anda membuat cabang persyaratan terpisah untuk setiap rilis baru, sementara semua dokumen di setiap rilis memiliki riwayat perubahannya sendiri. Beralih di antara versi rilis dilakukan dalam beberapa klik. Selain itu, Anda dapat membandingkan persyaratan dari rilis berbeda dan versi berbeda dari dokumen yang sama dalam rilis yang sama.







Beginilah tampilan beralih antar versi rilis dalam kehidupan nyata:

Berkomentar

Kami menggunakan plugin Talk untuk bekerja dengan komentar .







Kelebihannya:

• Anda dapat melihat komentar dan membalasnya dalam mode pengeditan dokumen. Ini sangat memudahkan ketika Anda perlu melakukan perubahan pada persyaratan berdasarkan hasil tinjauan
• Tidak ada masalah dengan komentar paralel (terutama jika Anda berencana untuk beralih dari MS Word + Sharepoint: Anda tidak perlu memblokir seluruh dokumen), persyaratan dapat ditinjau secara bersamaan oleh seluruh tim proyek
• Jika komentar ditinggalkan di halaman fitur dalam blok Multi Excerpt, secara otomatis muncul di dokumen persyaratan asli

Selain itu, ia memiliki fitur bagus seperti menyoroti komentar dalam berbagai warna, mengelola visibilitas untuk pengguna dan suka yang berbeda.



Kami mengabaikan fungsi komentar standar di Confluence, karena memiliki kekurangan yang sangat penting bagi kami:

• Tidak dapat digunakan bersama dengan plugin Multi Excerpt
• Komentar tidak terlihat dalam mode pengeditan dokumen
• Komentar hilang jika Anda mengubah teks yang dilampirkan

Membuat bagan dan maket

Pertama, kami menggunakan MS Visio dan mengekspor diagram dalam format bitmap, lalu memuatnya ke Confluence. Pendekatan ini tidak nyaman - relevansi skema harus dipertahankan di dua tempat, dan ini membutuhkan terlalu banyak tindakan.



Ternyata, Confluence memiliki banyak plugin untuk bekerja dengan semua jenis objek grafis (diagram, diagram, maket, dll.). Balsamiq Wireframes untuk Confluence dan Draw.io Diagrams for Confluence memungkinkan Anda untuk mengedit objek grafik tanpa meninggalkan Confluence. Saat ini, plugin ini hampir sepenuhnya memenuhi kebutuhan kita.

Fitur dasar

Saya akan secara singkat berbicara tentang kemampuan dasar yang disediakan Confluence (seperti kebanyakan wiki lainnya). Agar tidak menceritakan kembali dokumentasi tersebut, saya akan membatasi diri pada daftar apa yang terutama kami gunakan:

• Perbandingan versi dokumen. Anda dapat dengan cepat memahami bagaimana fungsionalitas telah berubah dari rilis ke rilis.
• P arallelnoe mengedit dokumen tunggal dan resolusi otomatis dari konflik. Beberapa orang dapat meninjau dokumen pada saat yang sama tanpa harus menunggu giliran mereka sementara dokumen dikunci untuk diedit oleh karyawan lain (seperti saat kami menggunakan Sharepoint dan persyaratan disimpan dalam bentuk file Word).
• Template dokumen. Kami telah membuat templat untuk semua jenis dokumen utama (modul fungsional, fitur, notulen rapat)
• Kemampuan kontrol akses yang fleksibel (hingga tingkat halaman). Ini nyaman, misalnya, untuk karyawan outsourcing yang tidak dapat diberi akses ke semua persyaratan sekaligus
• Ekspor dokumen dalam berbagai format. Ini sangat membantu dalam kasus yang jarang terjadi ketika diperlukan untuk mentransfer dokumen ke luar.
• Integrasi dengan JIRA. Anda dapat secara otomatis memasukkan status tugas, persetujuan dan informasi lainnya dari tiket JIRA.

Bermigrasi dari MS Word

Ada beberapa hal tidak jelas yang Anda temui segera setelah beralih dari Word ke Confluence.

Judul penomoran

Untuk menambahkan penomoran otomatis dari heading, Anda perlu membingkai teks dengan makro Numbering heading.

Hyperlink ke bagian

Untuk merujuk ke beberapa bagian dokumen atau judul bagian di dalam dokumen, Anda harus terlebih dahulu menambahkan makro Jangkar (dalam bahasa Rusia disebut "Jangkar"), dan kemudian menambahkan hyperlink ke dalamnya dari bagian yang diperlukan dari dokumen.

Warna latar belakang teks

Anda

dapat menggunakan markup Markdown (Insert -> Markup, Markdown) untuk menyesuaikan desain visual teks, khususnya untuk menyorot latar belakang teks dengan isian.









Ini sangat tidak nyaman, tetapi kami belum menemukan cara lain untuk memilih teks dengan isian.

Kekurangan:

• Menyalin dan menempelkan teks yang diberi markup dengan cara ini dari papan klip biasanya menyebabkan hilangnya markup.
• Anda hanya dapat mengubah markup dalam mode edit kode sumber halaman.

Itu saja. Ajukan pertanyaan di komentar!



PS Artikel ini didasarkan pada laporan "Confluence Life Hacks for Requirements Development" pada konferensi Analyst Days, versi video dari laporan ini dapat dilihat di tautan ini .



Penulis artikel: Ilshat Gabdullin g1r