Bagaimana Anda menganjurkan tidak menggunakan spreadsheet bersama untuk melacak bug / masalah?


14

Di perusahaan kami, pengembang ingin menggunakan alat pelacak bug yang tepat untuk mengatasi masalah dalam aplikasi kami. Namun manajemen bersikeras menggunakan spreadsheet bersama (secara formal file excel bersama, sekarang spreadsheet pada solusi berbasis web yang memungkinkan akses bersamaan).

Argumen mereka adalah bahwa spreadsheet memungkinkan mereka untuk memiliki pandangan tingkat proyek yang lebih tinggi karena mereka dapat melihat berapa banyak bug yang terbuka dengan pandangan sekilas. Ini juga memungkinkan mereka untuk melihat siapa yang mengerjakan setiap bug, dan mendapatkan estimasi waktu yang diperlukan untuk menutup semuanya (karena pengembang diharuskan mengisi estimasi waktu bug yang mereka kerjakan).

Seperti yang dapat Anda pahami, ini tidak terlalu praktis untuk digunakan oleh pengembang (perangkat lunak pelacakan bug diciptakan karena suatu alasan). Jadi, bagaimana saya bisa menganjurkan perangkat lunak pelacakan bug untuk memudahkan pekerjaan pengembang?

Sebagai bonus, perangkat lunak mana yang akan Anda rekomendasikan agar manajemen dapat memperoleh umpan balik mereka (jumlah bug terbuka, siapa yang mengerjakannya, estimasi waktu) dengan tampilan tingkat tinggi?


Sayangnya, lebih sering daripada tidak, manajemen telah mengambil keputusan.
kirk.burleson

4
Tunjukkan pada mereka eusprig.org/stories.htm . Atau bahkan hanya kehilangan 24 juta TransAlta karena kesalahan salin-tempel di EXCEL. Heck, Anda tidak ingin menggunakan program yang memungkinkan siapa pun untuk mengubah apa saja dengan cara yang benar-benar tidak terkendali. Alat terburuk untuk manajemen adalah Excel, dan itu terbukti berkali-kali. Ini juga merupakan artikel yang menarik: skillsportal.co.za/page/training/articles/…
Joris Meys

Apakah Anda setidaknya memiliki pelacakan versi dalam file Excel? Jika tidak, sebaiknya Anda menggunakan papan tulis.
Wonko the Sane

Mantis gratis, Anda dapat menginstalnya dalam waktu sekitar 2 jam, dan itu memberi Anda statistik dan hal-hal. Sebagai bonus, Anda dapat dengan mudah mengalokasikan bug ke rilis & pengembang, mengubah status, memaksakan alur kerja, mencatat komentar dan komentar, melampirkan email atau file lain. Daftar ini terus berlanjut. Spreadsheet adalah primitif, tidak terkendali, tidak efisien, dan jauh lebih efektif. Kami juga rentan terhadap kesalahan manusia dan tidak meninggalkan jejak audit.
cepat,

2
buka spreadsheet pada workstation yang tidak digunakan sehingga terkunci untuk mengedit, matikan layar, dan berpura-puralah Anda tidak tahu apa yang salah ketika tidak ada yang bisa memperbarui spreadsheet. ;-)
Steven A. Lowe

Jawaban:


22

Jadi, bagaimana saya bisa menganjurkan perangkat lunak pelacakan bug untuk memudahkan pekerjaan pengembang?

Diberikan pernyataan ini:

spreadsheet memungkinkan mereka untuk memiliki pandangan tingkat proyek yang lebih tinggi karena mereka dapat melihat berapa banyak bug yang terbuka dengan pandangan sekilas.

Anda perlu melihat sistem yang memiliki alat pelaporan yang secara efektif memungkinkan pembuatan spreadsheet dalam "waktu nyata" (atau sedekat mungkin dengannya). Ketika Anda menemukan salah satu dari ini menjelaskan bahwa memiliki pengembang menggunakan sistem yang "tepat" akan berarti bahwa data yang mereka minati akan (semoga) lebih akurat dan terkini (misalnya).


5

Versi spreadsheet mana yang terkini? Siapa yang punya spreadsheet itu?

Bugtracker yang layak akan melakukan apa yang dapat dilakukan spreadsheet, hanya:

  • akan mengirim email kepada pihak terkait ketika ada perubahan
  • menyediakan sumber kanonik tunggal untuk informasi terkini
  • memungkinkan untuk ringkasan laporan, untuk memberikan pandangan tingkat tinggi tentang keadaan proyek

Untuk proyek pribadi saya, saya menggunakan Mantis (hanya karena sangat mudah diatur). Pekerjaan menggunakan Trac dengan integrasi Mercurial.

Mantis menyediakan hal-hal seperti jumlah bug yang dibuka / ditutup / ditugaskan di luar kotak, dan saya membayangkan sebagian besar bugtrackers akan melakukannya. Saya tidak tahu tentang perkiraan waktu, karena saya tidak repot-repot mencari. Trac (atau instalasi di sini di tempat kerja) memang memiliki estimasi waktu, dan mudah untuk menulis laporan kustom yang akan, katakanlah, jumlah estimasi per tonggak.


5

Jawaban semua orang baik. Satu aspek lain terjadi pada saya.

Bagaimana dengan keamanan di sekitar spreadsheet. Bukankah seharusnya manajemen khawatir bahwa pengembang acak mana pun dapat secara tidak sengaja menekan tombol CTRL + A, HAPUS dan benar-benar mengacaukan segalanya? Sistem pelacakan bug yang tepat tidak akan memungkinkan terjadinya korupsi data semacam ini. Dan itu bahkan tidak memperhitungkan kedengkian. Bagaimana jika pengembang tertentu menginginkan lebih banyak kredit dan mulai menugaskan kembali semua perbaikan yang rusak pada dirinya sendiri. Sistem nyata akan memiliki jejak audit di mana hal semacam itu akan terlihat. Spreadsheet tidak akan.


4

Anda perlu menunjukkan kepada Manajemen bahwa persyaratan mereka akan dipenuhi.

Argumen mereka adalah bahwa spreadsheet memungkinkan mereka untuk memiliki pandangan tingkat proyek yang lebih tinggi karena mereka dapat melihat berapa banyak bug yang terbuka dengan pandangan sekilas. Ini juga memungkinkan mereka untuk melihat siapa yang mengerjakan setiap bug, dan mendapatkan estimasi waktu yang diperlukan untuk menutup semuanya (karena pengembang diharuskan mengisi estimasi waktu bug yang mereka kerjakan).

Jadi siapkan sistem dummy dan tunjukkan pada mereka dengan demo bahwa mereka bisa mendapatkan info ini sebaik dan mungkin bahkan lebih baik daripada menggunakan Spreadsheet.


4

Sejauh ini semua orang memberikan tanggapan yang serupa dan tepat. Ada satu aspek penting yang belum diucapkan. Untuk melacak bug dan memastikan tidak ada celah, Anda perlu dua hal:

  • Pelaporan yang baik, baik ringkasan maupun detail - ini bisa dicari nanti
  • Semua orang perlu tahu di mana salinan terbaru.

Di hampir setiap lingkungan yang menganjurkan menggunakan spreadsheet Excel, ada salinan berbeda spreadsheet ini di mesin setiap orang - dan tidak ada yang sama. Ini membuat proses meninjau kemajuan menjadi sangat sulit dan kontraproduktif.

Server terpusat seperti Trac, RedMine, JIRA, Mantis, atau apa pun yang Anda inginkan menangani kedua masalah tersebut. Pada titik itu, ini adalah masalah yang paling sesuai dengan kebutuhan perusahaan Anda. Bergantung pada lingkungan Anda, alat-alat ini dapat berintegrasi dengan IDE Anda seperti halnya sistem kontrol versi Anda (Eclipse memiliki fitur ini). Itu membuat bekerja melalui bug yang ditugaskan Anda jauh lebih mudah.


File dibagi secara terpusat; mengapa perlu ada salinan tambahan?
JeffO

2
Tidak pernah perlu . Ini pasti terjadi.
Berin Loritsch

Nah, saat ini kami menggunakan solusi berbasis web untuk mengedit spreadsheet bersama. Jadi duplikasi seharusnya tidak terjadi.
Sylvain Defresne

4

Saya tidak tahu lingkungan Anda, tetapi untuk pengguna Visual Studio, saya sangat menyarankan TFS. Ini mengintegrasikan kontrol sumber dan pelacakan masalah, dengan kemampuan pelaporan lengkap. Ini juga menawarkan lapisan otoritas, pelacakan riwayat lengkap (yaitu siapa yang memperbarui bug kapan, dan jika diatur, mengapa), memungkinkan Anda membedakan antara "bug" dan "masalah" dan "peningkatan" dan apa pun yang Anda inginkan suka, dan sepenuhnya terintegrasi dengan Visual Studio IDE. Itu mengikat bug dengan kode yang telah diperiksa, yang dapat diikat ke build tertentu. Dan masih banyak lagi.

Saya telah menggunakan banyak sistem kontrol sumber yang berbeda (VSS, SVN, TFS ...) dan banyak sistem pelacakan bug (sistem kepemilikan khusus, Pelacak, SharePoint, dan ya, bahkan Excel), tetapi untuk uang saya (dan itu adalah sejumlah besar perubahan), TFS bernilai investasi dalam uang dan waktu.

Dan ya, Anda dapat mengekspor ke (dan mengimpor dari) Excel.


2
Kami menggunakan Team Explorer dengan TFS, di mana Anda benar-benar dapat membuka Daftar Bug sebagai spreadsheet, pilih "Refresh" dari menu Tim, dan di sana Anda pergi, daftar bug terbaru di Excel tetapi dengan sistem pelacakan bug lengkap di belakangnya di TFS.
Marcie

1
Plus ada hal "dashboard" (berdasarkan Sharepoint) yang mencakup pustaka dokumen yang tampaknya memiliki spreadsheet di dalamnya. Ketika Anda membuka spreadsheet itu diisi dengan menarik kueri dari repositori. Manajer dapat memperbarui pri, upaya yang dibagikan, dan apa pun yang mereka inginkan menggunakan Excel, lalu klik Terbitkan dan kembali ke repositori. Mereka mendapatkan semua Excel yang mereka inginkan sementara devs mendapatkan semua associate-checkin-to-WI, add-a-screenshot-of-the-problem, see-my-task-in-Visual-Studio, dll-ness yang mereka inginkan.
Kate Gregory

2

Untuk membantu menjual transisi ke pelacak masalah yang tepat, Anda harus mencoba mencari tahu masalah apa yang dimiliki manajemen dengan sistem Anda saat ini (pasti ada 'akan lebih baik jika ...') dan lihat apakah Anda tidak dapat menggaruk gatal itu untuk mereka.

Membaca argumen manajemen

Argumen mereka adalah bahwa spreadsheet memungkinkan mereka untuk memiliki pandangan tingkat proyek yang lebih tinggi karena mereka dapat melihat berapa banyak bug yang terbuka dengan pandangan sekilas. Ini juga memungkinkan mereka untuk melihat siapa yang mengerjakan setiap bug, dan mendapatkan estimasi waktu yang diperlukan untuk menutup semuanya (karena pengembang diharuskan mengisi estimasi waktu bug yang mereka kerjakan).

Saya setuju dengan mereka semua dan setiap orang bertemu dengan JIRA (saya menyebutkan JIRA hanya karena itu yang saya gunakan, saya yakin ada kandidat yang berharga lainnya)

Anda perlu menekankan bahwa dengan alat seperti JIRA, mereka tidak hanya akan mempertahankan semua keuntungan dari pengaturan Anda saat ini, mereka juga akan mendapatkan banyak keuntungan baru.


2

Waktu cerita.

Beberapa bulan yang lalu saya kembali dari liburan selama satu minggu dan mendapati seluruh perusahaan saya berubah pikiran. Sebuah proyek yang telah dilakukan bagian lain dari departemen pengembangan selama berbulan-bulan tiba-tiba menjadi prioritas yang sangat mendesak, dan seluruh tim ditarik dari apa yang sedang mereka kerjakan untuk mengolahnya. Dalam pertemuan hari itu, pemilik perusahaan meminta kami untuk merobohkan beberapa karya hari itu dan sisanya pada hari berikutnya dan kami akan berada dalam kondisi yang baik.

Enam minggu kemudian kami akhirnya mengirimkan barang itu, setelah cukup banyak siklus kerja / tidur tanpa henti.

Metrik kami untuk "selesai" adalah bahwa klien tidak memiliki umpan balik lagi. Hal-hal baru dan menarik akan muncul pada setiap versi umpan balik mereka (dikirimkan kepada kami melalui email) yang belum pernah muncul sebelumnya, dan setiap kata yang mereka katakan adalah bagian langsung dari spec (dibenarkan dengan frasa "mari kita selesaikan ").

Pada suatu malam, saya baru saja benar-benar panik HAD IT dengan mengelola laporan bug melalui email dan printout-dengan-cek. Saya menginstal Mantis di server pengujian kami dan memuat dokumen umpan balik yang baru saja saya terima untuk bagian saya ke dalamnya. Saya mengatur manajer saya sebagai pengguna dan membiarkannya mulai menerima email darinya saat saya menutup masalah.

Dalam waktu sekitar 6 jam saya memiliki seluruh tim di dalamnya. PM menyaring email klien ke Mantis, pengembang mengklaim dan daftar masalah yang sedang berjalan. Bahkan lebih baik, mereka dapat meminta klarifikasi dan komunikasi di dalam sistem, menghasilkan jejak kertas tanpa kertas detail tentang setiap item.

Keesokan harinya mereka meminta saya untuk memimpin Tech sisa proyek. Rasanya seperti diberi granat hidup, tetapi saya mengambilnya dan berlari dengannya. Dua minggu kemudian kami akhirnya kehabisan kemampuan klien kami untuk menarik cincin hidung kami, dan menempatkan situs ke dalam produksi. Mantis sekarang bagaimana kami mengelola bug, dan mungkin menjadi bagaimana kami menangani permintaan fitur dari awal proyek.

TL; DR: Instal sendiri dan mulailah menggunakannya untuk barang-barang Anda sendiri. Biarkan itu membuktikan nilainya sendiri.

BTW, ini adalah kebijakan yang sama yang saya ikuti tentang kontrol versi. Kami menggunakan Subversion di bawah kebijakan yang diperlukan kunci, karena manajer saya tidak mempercayai penggabungan file. Tidak apa-apa, tetapi setelah saya memeriksa proyek SVN, saya segera membuat repositori git lokal untuk saya gunakan sendiri dalam pengembangan.



0

Anda perlu membuat spreadsheet yang ketika manajer membukanya, semua data pelaporan yang diperlukan diperbarui dari aplikasi pilihan Anda. Jika Anda membuatnya berfungsi, tidak ada argumen.


Itu tidak akan pernah berhasil. Entah karena kecelakaan atau kedengkian, cepat atau lambat seseorang akan merusak sistem "sangat mudah".
AShelly

0

hal-hal yang bisa salah dengan spreadsheet pelacakan bug pada jaringan berbagi:

  • tidak ada orang lain yang bisa mengeditnya ketika seseorang membiarkannya terbuka, lalu mengunci workstation dan pergi makan siang.
    • solusi "jelas" adalah menyimpan versi baru untuk penulisan. Ini menciptakan cabang - dan Excel buruk dalam penggabungan. Pekerjaan seseorang akan hilang.
  • dokumen dapat disimpan dengan baris tersembunyi, masalah diabaikan selama berminggu-minggu.
  • apa pun dapat dihapus dan pelacakan riwayat adalah marginal. "Apa yang terjadi dengan analisis masalah terperinci yang saya masukkan minggu lalu?"
  • mudah untuk menambahkan nilai ke bidang 'terbatas'. "Bagaimana tingkat keparahan bug ini ditandai 'Kegagalan Epik'?"
  • potong dan tempel rumus yang ditimpa. Suatu perhitungan dapat dengan mudah menjadi konstanta.

Saya sudah menjalani semua ini. Dan kami masih berhasil mengirimkan ... Hanya terlambat tiga bulan dan menghabiskan ribuan jam lembur yang tidak terencana.


0

"Gratis!" biasanya argumen yang cukup bagus. Pivotal Tracker gratis, tidak memerlukan instalasi, dan bisa dengan mudah memberikan manajer Anda tampilan tingkat tinggi yang lebih baik atas hal-hal daripada yang mungkin dengan spreadsheet rendah.

Edit:

Sangat menjengkelkan saya, baru saja diumumkan bahwa Pivotal Tracker tidak akan bebas lebih lama. :(


Saya sudah mencoba argumen ini. Tidak menang, karena saya diberitahu harga bukan masalah.
Sylvain Defresne

Saya kira Anda terjebak dengan argumen "Unggul Dalam Segala Hal". :-)
Nick Spreitzer

Sebenarnya banyak orang akan mengasosiasikan gratis dengan omong kosong. Saya menyarankan alternatif gratis untuk sesuatu dan bos saya menjawab "Kami hanya menginginkan yang terbaik" atau yang serupa. Di pasar bebas ini biasanya benar, tetapi mungkin tidak selalu berlaku untuk open source tentunya. Tidak banyak orang yang benar-benar memahami model open source, jika itu komersial dan gratis, ia akan memiliki suatu string.
Keyo

Itu sebabnya Anda perlu menindaklanjuti "gratis" dengan "dan itu luar biasa".
Nick Spreitzer

1
Hanya saja, jangan repot-repot menyebutkan gratis
Murph
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.