Apakah ada studi tentang kelemahan menggunakan sistem pelacakan masalah? [Tutup]

9

Saya tidak suka sistem pelacakan masalah karena:

Terlalu banyak waktu untuk menggambarkan masalah di dalamnya. Ini mencegah penggunaannya.
Anda membuat tempat untuk menyimpan bug Anda. Dan jika ada tempat untuk mereka, orang biasanya tidak terlalu peduli memperbaiki bug karena mereka dapat menaruhnya di sana sehingga suatu hari seseorang dapat memperbaikinya (atau tidak).
Seiring waktu, daftar bug menjadi begitu lama sehingga tidak ada yang bisa mengatasinya lagi, menghabiskan banyak waktu kita.

Saya lebih suka menangani masalah menggunakan post-it di papan tulis, percakapan tatap muka dan membunuh bug penting segera setelah muncul. Saya tidak terlalu peduli untuk melacak sejarah bug karena saya tidak berpikir itu sepadan.

Apakah saya sendirian di sini? Apakah ada studi (buku / artikel / apa pun) tentang kerugian (atau keuntungan besar) menggunakan sistem pelacakan masalah?

project-management agile issue-tracking

— pengguna1062120
sumber

5

Voting untuk ditutup, terlalu dilokalkan. Masalahnya di sini tampaknya bukan dengan sistem pelacakan masalah, melainkan dengan proses penanganan bug di perusahaan.

— P.Brian.Mackey

1

Sistem pelacakan masalah apa yang sudah Anda coba (selain post-it note dan whiteboard)? Bagaimana proses penggunaannya?

— FrustratedWithFormsDesigner

1

Dari mereka, saya hanya menggunakan Jira (saya setuju bahwa tampaknya ada banyak overhead, sampai Anda terbiasa dengan "ritme" -nya). Bukan penggemar web UI, tapi itu menyelesaikan pekerjaan. Di sini, kami juga menggunakan MKS, yang juga melakukan kontrol sumber. Ini lebih baik daripada Jira. Tak satu pun dari mereka yang sempurna, tetapi mereka semua masih lebih baik daripada kertas dan kenangan organik orang yang bisa keliru.

— FrustratedWithFormsDesigner

15

Saya kira saya bingung dengan pertanyaan itu. Menggunakan post-it di papan tulis ADALAH sistem pelacakan masalah. Jika proyek / tim / basis kode Anda cukup kecil dan post-nya + berhadapan langsung berhasil, Anda mungkin akan kesulitan meyakinkan diri sendiri untuk menambahkan lebih banyak overhead ke proses. Ada banyak sisi buruk untuk menggunakan sistem seperti itu, seperti disebutkan di bawah ini. Segera setelah proyek dan tim tumbuh, terutama ketika anggota tim mungkin tidak berada di gedung, kota, atau negara yang sama, sistem lain mulai bersinar seperti dicatat dalam jawaban di bawah ini.

— s_hewitt

2

bagaimana Anda melampirkan jejak stack ke posting itu? atau tangkapan layar? atau pesan kesalahan?

— jk.

41

Terlalu banyak waktu untuk menggambarkan masalah di dalamnya. Ini mencegah penggunaannya.

Jika Anda bahkan tidak dapat menggambarkan bug, bagaimana Anda bisa mulai memperbaikinya?

Anda membuat tempat untuk menyimpan bug Anda. Dan jika ada tempat untuk mereka, orang biasanya tidak terlalu peduli memperbaiki bug karena mereka dapat menaruhnya di sana sehingga suatu hari seseorang dapat memperbaikinya (atau tidak).

Itu adalah masalah dengan tim Anda bukan dengan perangkat lunak.

Seiring waktu, daftar bug menjadi begitu lama sehingga tidak ada yang bisa mengatasinya lagi, menghabiskan banyak waktu kita.

Sekali lagi Anda menggambarkan masalah dengan tim Anda.

Maksud dari perangkat lunak pelacakan bug bukanlah untuk membantu Anda memotivasi tim Anda untuk memperbaiki bug, itu untuk menyimpan catatan sehingga Anda dapat melacak penyebab bug dan menghentikannya terjadi lagi. Tidak ada perangkat lunak yang akan menjadi pengganti untuk manajemen yang baik.

— Tom Squires
sumber

Perangkat lunak pelacakan juga membantu melacak bug yang harus diperbaiki. Catatan tempel dapat jatuh, dan jika empat orang mendatangi Anda dengan bug yang dapat Anda kerjakan saat itu juga, Anda mungkin memperbaiki tiga dan melupakan yang keempat. Ini berguna bahkan jika Anda tidak memperhatikan penyebab bug.

— David Thornley

dan untuk memperbaiki masalah dengan tim Anda, Anda dapat menggunakan gamification -> en.wikipedia.org/wiki/Gamification

— marc.d

11

@JoaoBosco: Tiket yang ditulis tangan hilang, dicoret-coret, dibuang secara tidak sengaja ... percakapan tatap muka sangat bagus kecuali ketika Anda menjelaskan bug kompleks kepada orang-orang yang tidak memiliki memori foto. Orang akan melupakan hal-hal dari percakapan, bukan karena mereka ingin tetapi karena itulah yang terjadi.

— FrustratedWithFormsDesigner

3

@ JoaoBosco: Bagaimana dengan tangkapan layar dari kesalahan GUI? Apakah Anda akan menggambar ulang dengan tangan? Sampel keluaran data yang salah (jika ini adalah kesalahan basis data, apakah Anda siap untuk menulis n baris dengan kolom m data yang salah dengan tangan)? Bentuk lain artefak digital yang dikaitkan dengan cacat yang tidak bisa diterjemahkan dengan baik ke catatan tempel? Semua hal itu dapat dengan mudah dilampirkan ke tiket dalam sistem pelacakan masalah. Dan jika Anda nantinya akan mengubah catatan tempel Anda menjadi file teks, mengapa tidak database yang memungkinkan Anda mengurutkan, memesan, mengelompokkan tiket Anda, kemudian sedikit lebih jauh ke pelacakan masalah.

— FrustratedWithFormsDesigner

10

@ user1062120: "Jika tidak ada tempat untuk menyimpan bug, orang-orang mulai memperbaikinya lebih sering" - atau mereka mulai mengabaikan dan melupakan bug. Ini bukan "trik untuk memotivasi orang" tetapi upaya yang masuk akal untuk mengubah kelebihan menjadi kekuatan.

— Michael Borgwardt

12

IMO titik awal Anda bias. Jika pengembang gagal memperbaiki bug, proyek akan gagal, apakah mereka melacak bug menggunakan alat pelacak bug yang tepat, post-it, pahatan batu, atau tidak sama sekali. Ini bukan kesalahan alat jika tidak digunakan atau disalahgunakan. (Yang mengatakan, tentu saja ada pelacak bug / masalah buruk di luar sana ... Saya bekerja pada sebuah proyek menggunakan alat yang sama sekali tidak memadai untuk pekerjaan ini, jadi saya pikir saya tahu betapa buruknya itu. Tapi ada juga yang bagus, yang membutuhkan upacara minimal dan biaya overhead, memungkinkan Anda untuk fokus pada informasi yang relevan.)

Namun, jika pengembang benar-benar peduli, dan proyeknya lebih besar dari ukuran sepele, dan ada lebih dari satu pengembang di dalamnya, dan ada semacam manajemen yang terlibat (yang semuanya cukup umum di proyek dunia nyata ), segera akan muncul pertanyaan seperti:

Manakah dari bug terbuka yang harus diperbaiki terlebih dahulu? (catatan: dalam proyek yang waras, ini harus diputuskan oleh pemilik produk dan / atau manajemen, BUKAN oleh pengembang - yang karenanya mereka harus mengetahui semua bug terbuka terlebih dahulu!)
Berapa banyak bug terbuka yang kita miliki, dan seberapa parahnya?
Yang mana dari ini harus diperbaiki sebelum kita siap untuk melepaskan?
Berapa banyak waktu untuk merencanakan perbaikan ini - sering mengarah ke: berapa banyak waktu yang dibutuhkan untuk memperbaiki bug secara rata-rata?
berapa banyak bug yang telah dilaporkan oleh klien dalam rilis terakhir?
siapa yang memperbaiki bug ini-dan-ini, kapan, dan perubahan apa (kode / konfigurasi / data) yang melibatkan perbaikan?
perbaikan bug apa yang termasuk dalam rilis yang baru saja kami publikasikan?
...

Bisakah Anda menjawab pertanyaan [pembaruan] berulang-ulang, andal dan efisien [/ pembaruan] ini berdasarkan catatan post-it Anda?

Ya, memasukkan data bug ke pelacak masalah memerlukan beberapa overhead. Namun, itu lebih dari kompensasi pada waktu dan upaya yang dihemat dalam mencari, dan membuat laporan seperti di atas, dari data bug yang disimpan.

— Péter Török
sumber

Post-it tidak akan menjawab semuanya. Itu hanya alat. Anda masih dapat memprioritaskannya, membuat statistik tentang bug terbuka, memperbaikinya, dll. Yang saya katakan adalah saya pikir sistem pelacakan masalah bisa lebih kontra-produktif daripada membantu Anda memperbaiki masalah manajemen yang Anda miliki.

— user1062120

7

@ user1062120: Dan yang dikatakan semua orang adalah Anda sangat, sangat salah. Pasca-nya adalah sistem pelacakan masalah, hanya yang sangat miskin yang tidak memiliki banyak fitur penting.

— Michael Borgwardt

@ user1062120, tentu saja secara teori semua ini dapat dijawab menggunakan catatan tempel - jika Anda menambahkan ID unik untuk masing-masing, terus tambahkan komentar riwayat terperinci pada mereka (sehingga Anda mulai memerlukan catatan tempel agak besar setelah beberapa saat :-), dan menghabiskan banyak waktu menyortir, menyortir ulang dan mengatur ulang mereka sesuai dengan pertanyaan saat ini (yang Anda mungkin perlu mempekerjakan orang baru dalam proyek yang lebih besar ;-).

— Péter Török

@ user1062120, mis. perencanaan menghasilkan Pertanyaan 1 di atas - mari kita susun catatan tempel sesuai dengan prioritas. Segera PM bertanya Q2: oops, atur ulang berdasarkan tingkat keparahan. Tapi Q1 masih terbuka, jadi sekarang mari kita mengurutkan semuanya berdasarkan prioritas. Ups, 3 post-its ditinggalkan karena mereka ada di meja Joe - mulai dari awal lagi! Kemudian Q6 - mari kita gali kotak-kotak yang menyimpan sejarah post-it, telusuri semuanya dengan tangan untuk menemukan yang tepat, kemudian cobalah membaca tulisan cakar ayam di punggungnya, dimaksudkan untuk menggambarkan perubahan ... oops, seseorang membuka sebuah jendela di dekatnya, buru-buru untuk menyelamatkan post-it Anda dari melarikan diri oleh angin ... dll.

— Péter Török

9

Metodologi Anda dapat digunakan untuk proyek yang sangat kecil dengan jumlah programmer yang terbatas. Setelah proyek menjadi lebih besar, memiliki sistem pelacakan masalah menjadi jauh lebih penting untuk koordinasi antara tim yang berbeda, terutama jika perbaikan akan dilakukan dalam rilis kode yang berbeda. Proyek kompleks akan memiliki banyak komponen / komponen bergerak, dan memastikan bahwa masalah dijadwalkan dan diperbaiki adalah bagian besar dari implementasi pelacakan masalah yang baik

Beberapa artikel / studi yang mungkin menarik bagi Anda termasuk artikel ini membahas penggunaan Jend Zend dan studi Perancis ini membahas penggunaan sistem pelacakan bug.

— JW8
sumber

1

Terima kasih banyak untuk referensi. Saya akan melihat mereka. Dan ya, itu bekerja dalam 3 tim kecil di sini.

— user1062120

2

+1 untuk referensi, yang diminta secara eksplisit dalam pertanyaan.

— mattnz

4

Mungkin ada studi, tetapi bahkan lebih baik adalah pengalaman yang diperoleh dengan susah payah dari orang-orang di lapangan. Sebagian besar sistem pelacakan masalah mengalami proses yang mendorong desain mereka. Pelacak isu seringkali perlu mendukung 2 kelas pengguna yang berbeda:

Tim pengembangan
Pengguna sistem

Cal Henderson (sebelumnya dari Flickr) memiliki posting yang bagus tentang desain banyak pelacak isu dan mengapa ia lebih suka pelacak isu GitHub (seperti halnya saya). Juga, Garrett Dimon membahas desain Sifter dan menggambarkan cara untuk menyederhanakan proses untuk pelacakan masalah yang lebih efektif . Saya telah mengadopsi beberapa ide dari kedua posting ini untuk membantu menyederhanakan alur kerja pelacakan masalah tim saya.

Semua yang dikatakan, masih tergantung pada orang-orang atas proses dan alat. Pemikiran umum saya adalah bahwa pelacak masalah cenderung membuat jaminan yang harus Anda kelola. Selama triase, orang lebih cenderung merasionalisasi apa yang bukan atau bukan bug. Dalam proses kami, kami mengambil keputusan segera setelah bug diajukan tentang apakah itu merupakan masalah atau tidak. Setelah keputusan itu dibuat, bug masuk ke Pivotal Tracker. Perbedaannya di sini adalah kita menggunakan Tracker untuk penentuan prioritas , bukan sebagai pegangan untuk hal-hal yang tidak ingin kita lakukan. Bahkan ketika kotak es mulai terlalu besar, saya secara aktif menghapus item, termasuk bug. Jika masalah cukup besar sehingga perlu ditangani, itu akan muncul lagi.

Kami jarang membutuhkan riwayat bug. Kadang-kadang, seseorang mungkin menyebutkan gejala bug dan kami dapat melakukan pencarian untuk melihat apakah itu terkait dengan beberapa masalah yang sudah kami tangani. Tapi itu jarang terjadi.

TL; DR Fokus pada proses Anda, pilih alat sederhana dan atasi masalah saat muncul.

— kstewart
sumber

Itulah yang saya maksudkan. Kami juga memprioritaskan item segera setelah muncul dan kami juga menghapus item yang tidak penting. Hal-hal penting akan kembali pada waktunya. Saya menemukan bahwa overhead untuk melacak semuanya tidak layak. Gagasan memiliki papan tulis post-it kecil adalah bahwa Anda secara fisik tidak dapat mendaftarkan semuanya, hanya hal-hal penting. Jadi trik ini memaksa Anda untuk menanganinya sesegera mungkin. Tapi itu kasus saya, jadi saya tidak yakin apakah itu akan berhasil di mana-mana.

— user1062120

2

membunuh bug penting segera setelah muncul

Sepertinya Anda mendobrak pintu terbuka di sini. Bug penting "terbunuh" sesegera mungkin, tidak peduli apakah Anda menggunakan pelacak masalah atau tidak.

Oh dan bagian "seperti yang terlihat" adalah BTW cukup licin. Dalam satu proyek kami memiliki bug penting yang mengancam untuk membuang seluruh produk keluar dari bisnis (apa yang bisa lebih penting?). Itu sangat rumit (kesalahan arsitektur) dan kami tahu akan butuh waktu lama untuk memperbaikinya. Pelanggan dengan ramah setuju untuk memberi kami waktu satu tahun untuk memperbaiki (sebelum menjatuhkan produk kami) dan kami melakukannya dalam waktu sekitar satu tahun.

Adapun pelacak masalah, saya telah menggunakan ini selama hampir sepuluh tahun dan sebagai aturan, semua programmer di sekitar saya menghabiskan sedikit waktu dengan pelacak (perhatikan saya berbicara tentang programmer; manajer adalah cerita yang berbeda). Saya telah melihat kasus (jarang) ketika tidak demikian - dalam semua kasus ini ada sesuatu yang rusak parah.

Mengenai studi tentang percakapan tatap muka vs pelacakan masalah, sekali lagi rasanya Anda membuka pintu di sini. Pelacakan masalah adalah komunikasi tertulis yang khas ; ada banyak penelitian yang menunjukkan bahwa untuk membahas berbagai hal, komunikasi face2face jauh lebih efisien daripada melalui telepon yang pada gilirannya jauh lebih efisien daripada tertulis .

Sebenarnya mengingat bahwa Anda bertanya tentang f2f rasanya Anda (salah) menggunakan pelacak untuk membahas berbagai hal - ini bukan tujuannya. Untuk mengetahui tujuan penggunaannya, cukup tulis namanya secara perlahan dan jelas: sistem pelacakan masalah .

daftar bug menjadi sangat panjang

Menurut pengalaman saya, keuntungan di atas bukan masalah.

Dengan daftar bug yang panjang, pengembang dapat mengatur antrian dan merencanakan perbaikan jauh di depan. Ini sama produktifnya dengan yang didapat; bagi saya ini pada dasarnya adalah nirwana ketika saya memiliki antrian untuk bekerja dengannya. Bug pertama - perbaikan - selesai, bug kedua - perbaikan - selesai, bug berikutnya - perbaikan - dilakukan dll. Tidak ada gangguan bodoh, tidak ada gangguan yang menyakitkan dengan percakapan f2f yang sangat efisien, aliran murni .

Saya hanya ingat satu kasus ketika daftar bug lama telah menjadi masalah. Itu terjadi ketika beberapa orang idiot di manajemen yang lebih tinggi memutuskan kebijakan yang memaksa pengembang untuk mengambil bug berikutnya dari tumpukan 50-100 hampir setiap hari. Sayang sekali. Kami membutuhkan beberapa bulan rasa sakit sampai kami menemukan cara untuk meningkatkan ini di atas kepalanya dan memperbaikinya.
Beberapa waktu setelah kami berhasil membuat alur kerja yang nyaman, kami menemukan bahwa "tumpukan tanpa akhir" kami secara ajaib menjadi kosong.

— agas
sumber

2

Saya baru-baru ini menghabiskan 2,5 hari mengarungi lebih dari 300 bug terbuka (kebanyakan UI) bertambah lebih dari setahun, semua ditugaskan baik untuk freelancer / pekerja magang yang sudah lama berlalu, atau kepada manajer proyek yang tidak punya waktu untuk berurusan dengan mereka. Saya menemukan bahwa saya dapat menutup sekitar setengah dari mereka yang sudah diperbaiki atau tidak lagi relevan. Sisanya diperbaiki pada tingkat yang layak setelah saya menugaskan mereka ke orang yang tepat. Sistem pelacakan bug digunakan dengan buruk, tetapi tanpa itu, semua bug itu (tidak ada show-stop, tetapi beberapa yang jelek) pasti akan dilupakan.

— Michael Borgwardt

1

@MichaelBorgwardt ya daftar begitu lama sehingga tidak ada yang bisa mengatasinya dalam pengalaman saya selalu bisa dikelola selama seseorang tidak dibekukan dengan angka yang menakutkan seperti 200, 400, 1000. Saya hanya melakukan pemeriksaan cepat karena penasaran - untuk tahun lalu saya memperbaiki 300+ masalah - Saya sendiri (!). Karena penasaran saya juga memeriksa orang lain di tim berpikir mungkin saya unik - tidak, perbaikan 200-400 / tahun hanya muncul tingkat rata-rata. Namun 500 bug menakutkan tampilan ini, mungkin hanya setengah tahun bekerja untuk 4-5 pengembang, sepotong kue :)

— Agas