Jira melawan kekacauan dalam pengembangan: bagaimana tidak kehilangan tugas

Dalam artikel sebelumnya , saya memberi tahu Anda apa add-on untuk Jira yang kami buat sehingga alur kerja menjadi senyaman mungkin, dan tiketnya sangat informatif. Pada artikel hari ini, kita akan memecahkan masalah lain.

Diberikan:

• Anda mengembangkan dan mendukung produk perangkat lunak kompleks yang dijalankan pada banyak klien.
  
• Anda memiliki beberapa tim teknik (backend, IT Ops, iOS, Android, web, dll.) Yang bekerja secara independen satu sama lain dengan backlog yang terpisah;
  
• Anda memiliki beberapa lini produk, yaitu, secara kasar, satu manajer produk memimpin beberapa proyek ke arahnya sendiri, manajer lain - dengan caranya sendiri;
  
• tim teknik Anda fungsional, yaitu, mereka tidak dialokasikan untuk area produk terpisah, tetapi menyelesaikan masalah semua unit sekaligus, melayani bagian tertentu dari tumpukan teknologi;
  
• dan tentu saja Anda menggunakan Jira!
  

Masalahnya:

• peserta proses tidak mengerti bagian teknik apa yang terdiri dari fitur dan apa lagi yang perlu dilakukan pada proyek saat ini;
  
• tim teknik bekerja pada proyek yang sama secara serempak: satu tim dapat menyelesaikan bagiannya sebulan yang lalu, dan yang kedua bahkan tidak dapat memulai sendiri, karena mereka lupa tentang bagiannya dalam aliran tugas yang lebih penting.
  

Ada masalah nyata dengan transparansi proses pembangunan. Ketika ada banyak proyek dan arahan, kebutuhan akan beberapa jenis alat magis yang menghilangkan kekacauan dan memberikan gambaran yang jelas sangat akut. Sayangnya, pengalaman kami menunjukkan bahwa fitur standar Jira tidak sepenuhnya mengatasi hal ini.

Apakah itu familier? Mari kita pikirkan apa yang bisa kita lakukan.

Struktur proyek

Saya akan menganalisis masalah menggunakan contoh pengembangan di Badoo. Jadi bagaimana proyeknya? Tahap apa yang dilalui proyek? Potongan apa yang fitur khas baru terdiri dari memerlukan partisipasi beberapa tim?

Ide dan desain

Manajer produk (PM), setelah menemukan apa yang dapat ditingkatkan dalam produk, menciptakan tiket PROD dengan jenis Project di Jira. Deskripsi tiket ini terdiri dari satu tautan ke sebuah halaman di Confluence (analog dari Wiki Atlas yang terintegrasi dengan Jira). Halaman ini kami sebut PRD (Dokumen Persyaratan Produk). Ini adalah elemen kunci dari pengembangan. Bahkan, ini adalah deskripsi terperinci tentang apa yang masih harus dilakukan dalam kerangka proyek.


Saat membuat dokumen ini, PM bekerja erat dengan perancang. Untuk ini, tiket PROD lain dengan tipe Desain dibuat. Di dalamnya, perancang menempatkan tata letak, set ikon, dll. Elemen-elemen ini kemudian dimasukkan ke dalam PRD untuk kejelasan, dan juga digunakan oleh tim teknik dalam pengembangan.

Setelah menulis dokumen, PM menyerahkannya untuk diskusi publik. Biasanya PM lain dan juga pimpinan dari tim teknik berpartisipasi dalam percakapan. Diskusi langsung di komentar di PRD. Ini nyaman, karena riwayat korespondensi tetap ada, dan semua peserta yang tertarik menerima pemberitahuan ketika komentar baru muncul. Berdasarkan diskusi, perubahan yang disepakati dibuat untuk PRD asli.

Ketika semua nuansa diklarifikasi, tiket PROD awal diterjemahkan ke dalam simpanan pengembangan yang tertunda. Setelah itu, sekali seminggu, tim produk mengurutkan simpanan ini sesuai dengan prioritas sesuai dengan tujuan perusahaan, perkiraan pembuangan dan kerumitan implementasi. Proyek-proyek yang diakui sebagai yang paling menjanjikan, beralih ke tahap berikutnya - dekomposisi. Untuk ini, tiket MAPI khusus (API Seluler) dibuat untuk tim arsitek sistem.

Penting untuk dicatat di sini bahwa untuk lebih cepat membuat tiket terkait dengan proyek, serta untuk menghilangkan faktor manusia (mereka lupa sesuatu, salah taut atau menandainya), kami mengotomatiskan proses ini. Jadi, misalnya, tiket root proyek di header memiliki dua tombol tambahan.



Yang pertama menciptakan tiket untuk desainer, yang kedua untuk arsitek sistem. Dalam hal ini, tiket baru secara otomatis diisi dengan atribut yang diperlukan: label yang benar, tautan ke PRD, templat uraian, dan yang paling penting - ditautkan satu sama lain.

Optimalisasi aliran ini diimplementasikan berdasarkan pada plugin Jira ScriptRunner , yang saya tulis di artikel sebelumnya .

Dekomposisi

Setelah menerima tiket MAPI baru dengan PRD yang menyertainya, arsitek sistem memutuskan:

• bagian mana dari logika yang harus diimplementasikan di sisi server, dan bagian mana di sisi klien;
  
• perintah apa yang harus dikirim klien dan respons apa yang harus diterimanya dari server;
  
• token mana yang harus "ditransfer" ke klien, dan yang harus datang dari sisi server.
  

Cukup sering, pada tahap ini, perubahan PRD terjadi. Arsitek menggali lebih dalam rincian implementasi daripada yang mereka lakukan ketika membahas PRD. Oleh karena itu, mungkin ternyata bahwa untuk mencapai tujuan bisnis proyek, dimungkinkan, dengan mengabaikan bagian dari persyaratan awal, untuk secara signifikan menyederhanakan pengembangan. Kami sangat menghargai inisiatif ini.

Anda dapat mempelajari lebih lanjut tentang cara kerja tim arsitek kami dan melihat deskripsi API kami dari laporan .

Hasil karya arsitek sistem adalah:

1. Munculnya dokumentasi teknis lengkap untuk proyek (deskripsi protokol interaksi klien-server dengan referensi ke kasus logika bisnis yang dijelaskan dalam PRD).
   
   
   Cuplikan layar bagian dari dokumentasi salah satu fitur kami yang saat ini tidak aktif

   
   
   
   
2. Protokol yang dimodifikasi (file dalam format Google Protocol Buffer) dalam repositori. Jika fitur baru atau perubahan yang lama diperlukan untuk mengimplementasikan fitur, mereka akan tersedia untuk pengembang semua tim.
   
3. Tiket untuk tim pengembangan dan pelokalan. Untuk ini, kami memiliki antarmuka khusus yang memungkinkan Anda membuat tiket yang diperlukan untuk semua tim yang terlibat sekaligus. Dibuka dengan tautan dari tiket MAPI.
   
   
   
   Dengan mengkliknya, antarmuka berikut yang dibuat oleh kami terbuka:
   
   
   
   Dengan mengklik tombol di bagian bawah formulir (tidak terlihat di tangkapan layar), tiket yang diperlukan akan muncul, yang akan secara otomatis ditautkan ke tiket MAPI asli. Perlu dicatat bahwa semua tim pengembangan bekerja di ruang kita sendiri (proyek) Jira: tim backend di SRV, tim Android di AND, tim web ada di Web, dll.
   
   Antarmuka didasarkan pada Jira REST API.
   

Dengan demikian, struktur proyek dapat digambarkan sebagai diagram berikut:

Pengembangan dan peluncuran

Dalam kasus umum, semua tim dapat mengerjakan proyek secara paralel, hanya menyentuh pada tahap akhir integrasi, yaitu, tim klien tidak harus menunggu server selesai untuk melakukan bagian mereka. Karena protokol interaksi dijelaskan secara rinci, selama pengembangan, Anda dapat dengan aman meniru respons server yang diharapkan dan men-debug logika klien. Selain itu, server tidak memerlukan klien selama pengembangan - programmer server hanya mengimplementasikan protokol dan menutupinya dengan tes, meniru permintaan klien.

Biasanya, fitur diluncurkan dalam skenario berikut:

1. Server adalah yang pertama untuk mengeluarkan bagian dari fungsionalitas, yang dicakup oleh flag fitur, dalam produksi. Dengan demikian, logika ini tetap tidak digunakan sampai salah satu klien mulai mengirim flag fitur ini.
   
2. Tim klien sebelum rilis dalam produksi menguji bagian mereka dari fungsionalitas yang sudah ada di server "pertempuran".
   
3. Segera setelah siap, klien yang berbeda dilepaskan, mulai mengirim bendera fitur yang diinginkan dan menerima respons server baru.
   

Kemungkinan kerja sinkron pada proyek adalah nilai tambah yang besar, yang secara signifikan dapat meningkatkan efisiensi pengembangan. Tetapi di sinilah risikonya: beberapa tim dapat “menulis ke meja,” yaitu, melakukan bagian pekerjaan mereka, yang tidak akan pernah diminati oleh peserta proyek lainnya. Mungkin ada beberapa alasan:

• prioritas berbeda untuk tim pengembangan; masalah biasanya tidak muncul ketika mengerjakan proyek yang sangat penting bagi perusahaan (mereka semua terkenal dan sulit untuk dilupakan), tetapi yang kurang penting dapat ditempatkan di tumpukan lokal tim terpisah di tempat terakhir;
  
• kesalahan manajemen proyek: manajer dapat dengan mudah lupa memprioritaskan tugas-tugas tim pengembangan dengan benar, yaitu, para pesertanya bahkan tidak akan tahu bahwa tiket harus diambil dalam pengembangan sesegera mungkin.
  

Bagaimana tingkat masalah ini? Bagaimana memastikan bahwa potongan-potongan proyek tidak hilang, dan tim memperhatikan proyek prioritas?

Fitur Standar Jira

Apa yang dapat ditawarkan fungsionalitas Jira standar kepada manajer proyek untuk menyelesaikan masalah ini? Tidak terlalu banyak:

• Filter
  
• papan kanban.
  

Filter

Filter memungkinkan Anda untuk melihat daftar linier tiket yang diterima untuk permintaan JQL sewenang-wenang. Alat ini sangat nyaman untuk melayani simpanan satu tim, tetapi saya tidak tahu bagaimana menggunakannya untuk manajemen proyek berkualitas tinggi, didistribusikan di berbagai tim. Maksimum yang dapat dilakukan seorang manajer adalah menampilkan daftar tiket PROD root yang diprioritaskan, dan kemudian Anda harus masuk ke masing-masing, melihat tiket yang ditautkan. Tapi ini sangat merepotkan dan panjang, terutama mengingat bahwa hierarki tautan bisa bertingkat. Selain itu, tim pengembang dapat membuat beberapa tiket tambahan untuk menyelesaikan tugas awal, dan status mereka juga harus dipantau.

Papan kanban

Bagi mereka yang tidak tahu cara kerjanya di Jira, saya akan menjelaskan. Secara umum, ini adalah daftar tugas berdasarkan filter tertentu, dikelompokkan ke dalam tiga kolom: "Backlog", "Tugas dalam pengembangan", "Tugas yang selesai". Antarmuka memungkinkan Anda untuk meningkatkan prioritas tugas hanya dengan menyeret tiket dalam daftar dengan mouse. Pada saat yang sama, properti Rank berubah, dimana Anda kemudian dapat mengurutkan tiket di filter Anda.

Di sini kita sudah memiliki lebih banyak ruang untuk menggunakan alat dalam konteks tugas yang dihadapi. PM dapat membuat filter yang memilih semua tugas semua departemen ke arah yang diinginkan. Ini dapat dilakukan, misalnya, dengan secara otomatis menempatkan tiket dengan label yang sesuai. Saya mengingatkan Anda bahwa semua tiket proyek utama untuk proyek kami dibuat menggunakan alat yang sesuai. Oleh karena itu, secara otomatis menyalin label yang diperlukan dari tiket-root ke semua tiket turunan adalah tugas teknis yang sepele.

Kami menggunakan papan kanban untuk membentuk dan mengontrol simpanan tim teknik. Menggunakan alat Swimlanes, papan dapat dikelompokkan ke dalam proyek-proyek yang sesuai dengan tim teknik. Dengan demikian, menggunakan alat ini, PM dapat memantau kemajuan proyek-proyeknya dalam konteks tim yang berbeda, serta memprioritaskan tiket tim.


Skema dewan kanban produk di mana tiket proyek PM dikelompokkan berdasarkan tim

Masalahnya adalah alat ini tidak menyediakan cara mudah untuk mengelompokkan tiket berdasarkan sumber tiket PROD, yaitu dengan fitur: Saya ingin memantau kemajuan setiap proyek secara individu di semua tim teknik.

Excel

Solusi paling jelas adalah dengan menggunakan spreadsheet. Lagi pula, Anda dapat melakukan semua yang Anda suka: nyaman, indah, informatif. Sesuatu seperti ini:



Anda dapat melihat lingkup pekerjaan umum untuk setiap proyek di satu tempat. Anda dapat membuat berbagai catatan, mencoret tiket yang sudah selesai, dll. Semuanya bagus di sini, kecuali satu yang berani, tetapi: mempertahankan relevansi tabel tersebut sangat sulit. Status tiket terus berubah, yang baru sedang dibuat. Membuat semua perubahan secara manual? Anda bisa menghabiskan sepanjang hari. Tapi kami untuk efisiensi, bukan?

"Dan mari kita menyeberang!"

Mengapa kita tidak menggunakan kenyamanan dan kejelasan spreadsheet dengan menambahkan sinkronisasi otomatis dengan Jira? Kami memiliki semua kemungkinan untuk ini! Jadi kami memutuskan untuk membuat alat tambahan berdasarkan Jira REST API, yang secara otomatis mempertahankan kondisi informasi saat ini dan memiliki antarmuka yang nyaman bagi kami.

Persyaratan alat adalah sebagai berikut:

• kemampuan untuk membuat daftar proyek dan turunannya dari tiket sesuai dengan permintaan JQL yang sewenang-wenang (ini diperlukan agar setiap PM dapat membuat ruang (unit) sendiri di mana ia hanya akan melihat proyeknya dan mengelolanya);
  
• proyek baru di Jira akan secara otomatis muncul di antarmuka;
  
• tiket baru dalam proyek akan secara otomatis muncul di antarmuka (yaitu, jika tim pengembangan memutuskan bahwa lebih banyak tiket diperlukan untuk mengimplementasikan fitur, maka PM akan segera melihat ini di antarmuka);
  
• tergantung pada status tiket, warna sel-sel tabel harus berubah (untuk pemahaman cepat oleh para peserta status proyek);
  
• kemampuan untuk menyortir proyek (memprioritaskannya dengan tepat);
  
• menyembunyikan otomatis proyek yang sudah selesai dua minggu setelah selesai.
  

PM mulai bekerja dengan alat ini, menciptakan ruang (unit) sendiri, menunjukkan namanya dan permintaan JQL:



Selanjutnya, permintaan dibuat untuk Jira untuk mendapatkan daftar proyek untuk permintaan JQL yang ditentukan. Juga menggunakan tautan di Jira adalah semua tiket turunan tim teknik. Hasilnya adalah sesuatu seperti tabel ini:



Di atas adalah tautan untuk beralih antar unit.

Baris tabel adalah tiket PROD root unit. Dalam sel kita melihat tugas-tugas proyek untuk departemen teknik tertentu. Pengisian berlangsung secara otomatis tunduk pada aturan untuk menghubungkan tiket proyek satu sama lain. Tahap yang selesai ditandai dengan warna hijau, tidak mulai dalam warna merah, dan arus berwarna kuning.

Tautan mengarah ke tiket ke Jira. Anda juga dapat memperoleh informasi singkat tentang tiket dengan mengarahkan kursor ke tautan:



Dengan frekuensi sekali setiap beberapa menit, permintaan dilakukan ke Jira API untuk mendapatkan daftar proyek terbaru untuk semua unit, untuk menyinkronkan daftar turunan tiket, serta status mereka saat ini.

Penyortiran dilakukan dengan hanya menyeret dan menjatuhkan proyek yang diinginkan ke lokasi yang diinginkan dalam daftar:



Penting untuk dicatat bahwa dengan alat ini di Badoo tidak hanya manajer produk bekerja, tetapi juga pemimpin tim teknik. Bagaimanapun, penting bagi semua orang untuk memahami apa yang terjadi di bidang produk, yang telah dikembangkan oleh tim dalam melaksanakan proyek-proyek penting bagi perusahaan lebih dari yang lain, dan yang ada di belakang.

Kesimpulan

Jira "out of the box" menyediakan fungsionalitas yang kuat untuk mengelola struktur proyek dan hubungan antar tiket. Ada juga plugin yang secara signifikan memperluas kemampuan JQL (misalnya, mereka memungkinkan Anda untuk menggunakan tautan antara tiket dan tipenya untuk memfilter tiket). Dalam kasus kami, kami hanya kurang memiliki kemampuan untuk memvisualisasikan semua yang kami butuhkan.

Untungnya, Jira memungkinkan membuat alat tambahan yang nyaman berdasarkan API-nya, disesuaikan dengan proses bisnis perusahaan. Jadi, misalnya, kami dapat menyelesaikan masalah yang muncul dengan transparansi melakukan proyek di selusin area produk, dengan sedikit usaha dan menggunakan fitur tambahan dari pelacak tugas ini. Akan menarik untuk membaca di komentar jika Anda mencoba untuk membuat add-on seperti itu di tempat Anda atau menemukan solusi lain untuk tugas Anda.

Terima kasih atas perhatian Anda!