Get best of the week

Cara bekerja secara efektif dengan isu-isu tentang GitHub

Tiket di GitHub berbeda: permintaan untuk penerapan beberapa fitur, laporan kesalahan, keluhan dari pelanggan, peringatan dari sistem keamanan, retrospektif untuk tim, dll. Di sini kita melihat bagaimana tim dapat menggunakan dan mendiskusikannya.

Kandungan:



Apa itu tiket?


Bagi banyak tim, "tiket" adalah istilah umum yang dapat berarti:

  • Permintaan implementasi fitur.
  • Laporan kesalahan.
  • Keluhan pelanggan.
  • Peringatan keamanan.
  • Retrospektif untuk tim.

Publik atau pribadi?


Untuk proyek, Anda dapat membuat tiket publik dan pribadi. Publik, sebagai aturan, ditujukan untuk pengguna, pelanggan, agen, dll. Pribadi - untuk pengembang, kontraktor, mitra, dll.

Untuk tiket publik


  • Fokus pada garis bawah.
  • Tekankan apa yang bisa dilakukan.
  • Jangan memposting informasi rahasia.

Untuk tiket pribadi


  • Fokus pada detail.
  • Sorot informasi penelitian, karena membantu mengidentifikasi kemungkinan pola di antara tiket yang berbeda.
  • Tambahkan informasi rahasia sesuai kebutuhan.

Peringkat


Semua tiket harus dievaluasi sedemikian rupa agar dapat membandingkannya satu sama lain dan memahami apa yang sebenarnya perlu dikerjakan. Ada berbagai cara untuk mengevaluasi, dan dalam praktiknya berikut ini bekerja dengan baik.

Peringkat Prioritas


  • Contoh : Prioritas 1 (lakukan dulu), Prioritas 2 (lakukan kedua), Prioritas 3 (lakukan ketiga), dll.
  • Analogi : daftar tugas di mana Prioritas 1 adalah prioritas utama.
  • : , . , .
  • : 0 (P0), , .


  • : 1 ( ) 5 ( ).
  • : - 1 (), 2 (), 3 (), 4 (), 5 ().
  • : . . , .
  • : 0 () 5 (). , .


  • : 1 ( ) 10 ( ).
  • : 1 ( ) 10 ( ).
  • : . . . , .


  • : — «», «», «».
  • : .
  • : , .

MoSCoW


  • : MoSCoW — «must», «should», «could», «won't». « », «», « », « ».
  • : , , - : « » « ».
  • : . .

    : «would» «won't», , , «would» , , - : « , ...».


  • : « 1 %» , 1 % , « 100 %» — .
  • Analogi : frekuensi kemunculan sesuatu atau pengulangan selama periode tertentu atau dalam sampel yang dimaksud.
  • Keuntungan : memungkinkan Anda mengevaluasi seberapa sering masalah terjadi. Dapat dikonversi ke nilai seperti "20 kali sehari." Anda dapat merangkum dalam bentuk "selalu", "sering", "kadang-kadang", "jarang", "tidak pernah". Itu dapat dinyatakan sebagai persentase: "80% kasus terpengaruh."

Peringkat kumulatif


Contoh : evaluasi tiket dengan kombinasi prioritas, pengaruh, kerusakan, ukuran, MoSCoW dan frekuensi.

Misalkan klien penting datang ke kantor untuk menandatangani perjanjian dalam waktu satu jam, dan tim penjualan menemukan kesalahan ketik atas nama perusahaan klien di situs.

  1. Penjual pertama-tama menetapkan tiket Prioritas 1.
  2. 1 ( ), .
  3. 3 (), .
  4. «» , .
  5. MoSCoW « », .
  6. 2 %, 2 % .


Berikut adalah contoh diskusi tentang peringkat tiket.

- Biasanya, selain dari bahaya, frekuensi juga dievaluasi secara independen. Jika bug tidak mungkin terjadi selama penggunaan normal, maka bahkan dengan risiko tinggi, prioritas dapat dikurangi. Ini biasanya bagaimana risiko dikelola.

- Pengembang atau penguji dapat dengan baik menilai bahaya bug, tetapi ia tidak tahu apakah semua pengguna atau hanya beberapa dari mereka akan menghadapi masalah ini. Frekuensi adalah dimensi lain. Prioritas dapat dihitung dengan mengalikan bahaya dengan frekuensi.

- Bentuknya harus sebagai berikut: bahaya * frekuensi - kemudahan penyelesaian = prioritas. Jika ada anggota persamaan yang berubah (misalnya, solusi baru ditemukan, atau ternyata hampir tidak ada yang masuk ke halaman web yang jatuh), maka prioritas akan disesuaikan. Hanya ada satu bahaya tanpa "memperkirakan jumlah orang yang akan terpengaruh" dan "seberapa besar dampaknya pada mereka?" Itu terlihat hanya sebagian dari gambar.

- Insinyur QA selama penelitian awal mengidentifikasi bahaya berdasarkan kriteria teknis. Ini hanya salah satu faktor yang digunakan spesialis produk dalam menentukan prioritas, yang sejak saat ini menjadi parameter utama.

- Untuk beberapa pengguna, program terkadang macet, mereka kehilangan semua pekerjaan yang dilakukan dan sangat marah. Mereka menetapkan bahaya tertinggi untuk tiket. Tetapi jika hanya satu orang yang menghadapi masalah, dan ini terjadi secara berkala, dan pengguna telah beradaptasi untuk menabung lebih sering, maka teknolog produk harus memberikan prioritas yang lebih rendah pada tiket.

- Bahaya mencirikan persepsi suatu masalah oleh seseorang: jika dia menemukannya dalam kasus tertentu, maka dia akan menilai bahaya secara maksimal. Prioritas menggambarkan bagaimana tim manajemen proyek melihat bug: bug yang dilaporkan oleh pengeluh paling berharga - pelanggan yang membawa banyak uang, direktur yang mengalami kesulitan, dll. Menerima nilai yang lebih tinggi. Jangan menggunakan bahaya bug untuk mengevaluasi prioritas, karena mereka saling berhubungan secara tidak langsung .

- Pengalaman menggunakan prioritas dan bahaya menunjukkan bahwa secara teori mungkin ada perbedaan di antara mereka, tetapi pada kenyataannya sebagian besar tidak melihatnya. Istilah-istilah ini seringkali membingungkan sehingga tidak dapat dipisahkan.

- Sistem pelacakan bug internal Google menangani prioritas dan bahaya. P0 S0 adalah tugas yang paling mendesak, P2 S2 adalah standar, P4 S4 adalah yang paling tidak mendesak. Ini adalah sedikit lelucon yang bertugas bahwa bahaya tidak masuk akal (karena sebenarnya tidak berbeda dari prioritas).

- Kami hanya menggunakan prioritas. Penguji memberikan nilai awal berdasarkan heuristik (misalnya, jatuh - P1, perbaikan kosmetik - P5). Pengembang berfokus pada nilai ini untuk memilih bug yang Anda harus mulai kerjakan terlebih dahulu. Dan kemudian prioritas disesuaikan sesuai dengan pengalaman pengguna dan perilaku aplikasi. Jika kita benar-benar perlu melihat nilai apa yang ditetapkan tester, maka kita menggunakan fungsi "histori" atau "revisi" dalam aplikasi kita untuk melacak kesalahan.

Template Tiket


Kerangka ini akan membantu tim Anda secara efektif dan komprehensif mencakup topik-topik penting.

Itu dapat menggunakan:

  • Pengadu utama: deskripsi umum tentang masalah yang diberikan oleh orang yang telah mengalaminya.
  • Peserta: yang terlibat dalam situasi - pengguna, karyawan, mitra, orang-orang tertentu, dll.
  • Gejala: tanda-tanda masalah yang jelas - pendapat pengguna, pemicu, peringatan, dll.
  • Sejarah: informasi sekunder yang relevan dengan situasi - kasus serupa, laporan, tautan, dll.
  • Diagnosis: apa yang terjadi di bawah tenda - penyebab mendasar atau rantai penyebab, dll.
  • Prakiraan: penilaian konsekuensi potensial, perubahan, dll.
  • Fraktur: kehilangan informasi, aplikasi macet, proses diblokir, dll.
  • Pengobatan: apa yang kami lakukan untuk memperbaiki situasi - prosedur, daftar tugas, batasan, dll.

File template penulis: TEMPLATE.md

Peluncuran postmortem


Peluncuran pesan post-mortem akan memberi tahu tim kapan harus menghadapi situasi tersebut.

Anda dapat menjalankan analisis:

  • Dengan masalah apa pun yang terlihat oleh pengguna, seperti crash atau kesalahan yang tidak terduga.
  • Dalam hal terjadi intervensi berdasarkan permintaan, misalnya, oleh insinyur atau manajemen.
  • Dalam setiap investigasi insiden, karena ini mencerminkan kebutuhan untuk pemantauan.
  • Dalam hal permintaan dari pihak yang berkepentingan untuk melakukan review, mengaudit atau mengurangi konsekuensi dari insiden.

Post-mortem yang tidak bersalah


Dengan post-mortem yang tidak bersalah, ada baiknya berfokus pada gejala, penyebab dan pengobatan, daripada menyalahkan seseorang. Ulasan semacam itu dimulai dengan konfirmasi bahwa setiap orang memiliki niat baik, bahwa segala sesuatu yang mungkin dilakukan menggunakan informasi yang tersedia saat itu.

More articles:


All Articles