Redmine praktik terbaik [ditutup]

Tip dan "standar" apa yang Anda gunakan dalam proses manajemen proyek Redmine?

Apakah Anda memiliki templat penyisipan wiki standar yang dapat Anda bagikan atau cara standar untuk mengerjakan proyek menggunakan tugas fitur bug dan masalah dukungan?

Apakah Anda membiarkan masalah dan pembaruan dikirim melalui email ke Redmine? Apakah Anda menggunakan forum? Apakah Anda menggunakan repositori SVN? Apakah Anda menggunakan Mylyn in eclipse untuk mengerjakan daftar tugas?

Saya mencoba menyeret dept kami. ke beberapa PM berbasis web alih-alih mengirim dokumen Word yang dikirim melalui email dengan persyaratan yang tidak jelas diikuti oleh dokumen Word yang menjelaskan cara QA dan Menerapkan bahwa semua tersesat dalam tumpukan pembaruan dan proyek yang bersaing sehingga pada saat saya harus memperbaiki sesuatu, tidak ada yang dapat menemukannya dokumentasi apa pun tentang cara kerjanya.

Saya mengembangkan dan memelihara aplikasi internal untuk keluarga perusahaan manufaktur. Sampai saat komentar ini dibuat, saya satu-satunya pengembang / analis di tim TI. Selama masa resesi terburuk, tuntutan proyek saya meledak. Dengan demikian proyek saya DAN masalah backlog cukup berat. Kami saat ini sedang dalam proses restrukturisasi untuk memperluas tim.

Inilah cara saya menggunakan Redmine untuk menjaga kepala saya tetap lurus (sejauh mungkin), pengguna saya menjauh, dan semoga mencegah terlalu banyak pegangan tangan staf baru di masa depan.

• Saya menggunakan Subversion untuk kontrol sumber, dengan TortoiseSVN dan plugin Tortoise-Redmine yang diberi nama tepat . Menyegarkan Repositori pada proyek Redmine setelah komit menautkan masalah, yang menunjukkan revisi masalah, dan memperbarui pemangku kepentingan saya melalui pemberitahuan email.
• Saya memperlakukan deskripsi proyek sebagai sarana untuk mengkomunikasikan tujuan, ruang lingkup, dan tahap siklus hidup proyek kepada mereka yang tidak terlibat. Dengan begitu, pengguna saya tahu apa yang saya dapatkan di piring saya, dan apa yang masih ada di prasmanan yang saya lihat dari kejauhan.
• Saya menggunakan nama peran tertentu untuk set izin saya yang menunjukkan lebih dari satu set izin - sekali lagi, sebagai sarana dokumentasi. Peran saya meliputi: Manajer Proyek, Anggota Tim Proyek, Pemilik, Pengguna Utama, Pengguna Sekunder, Pengamat, Tuan (untuk atasan saya ... menyenangkan dan benar).
• Saya menggunakan Wiki dan Dokumen untuk dokumentasi, tergantung mana yang menurut saya sesuai.
• Versi cukup banyak tidak berguna bagi saya, jadi daripada menggunakannya untuk rilis yang direncanakan, saya menggunakannya untuk mengelompokkan masalah terkait ke dalam sprint.
• Saya menggunakan plugin Stuff-To-Do yang luar biasa dari Eric Davis untuk mengatur / mengatur ulang sprint yang disebutkan di atas sebelum mengedit Versi Target secara massal pada masalah saya. Ini juga memberi tahu pemangku kepentingan saya apa yang saya kerjakan dan bagaimana saya memprioritaskan kepentingan mereka (baik atau buruk).
• Untuk mendorong interaksi pengguna, saya menambahkan tautan ke proyek Redmine ke dalam menu Bantuan aplikasi saya. Kotak "Tentang" juga berisi tautan ke proyek Redmine.

Rencana masa depan

• Saya berharap pada titik tertentu untuk menyelesaikan ekstensi Visual Studio saya untuk integrasi Redmine.
• Bangun pustaka kode untuk memasangkan aplikasi saya secara longgar dengan proyek Redmine: mengotomatiskan pengiriman bug, memperingatkan pemangku kepentingan yang berlangganan dari baki sistem, menu Bantuan interaktif yang dapat digunakan kembali yang didorong oleh API REST Redmine, dll. (Mungkin mengotomatiskan bagian dokumentasi dengan Wiki?)

Saya adalah pengembang web Ruby dan Redmine freelance yang menjalankan bisnis pengembangan satu orang (saya). Jadi Redmine saya diatur agar cukup ringan dan fokus pada pelanggan. Redmine saya juga melayani tugas ganda untuk menghosting proyek Open Source saya.

Saya mengizinkan masalah baru dan pembaruan untuk dikirimi email dan berfungsi dengan baik untuk pengguna yang terhubung dengan email (atau mereka yang selalu menggunakan iPhone mereka).

Saya telah menggunakan tampilan repositori dengan repositori git dan berfungsi dengan baik. Dengan setiap check in, saya merujuk masalah dengan #nnn sehingga halaman masalah yang sebenarnya akan menampilkan semua komitmen untuk menerapkan fitur tersebut.

Saya menemukan forum kurang dimanfaatkan. Saya pikir jika ada beberapa integrasi email, itu akan lebih berguna.

Kami menemukan praktik-praktik berikut berguna:

1) Sembunyikan pelacak "Masalah" dan "Dukungan", dan laporkan semuanya sebagai bug :

• penghemat waktu untuk pengembang, penguji, manajemen;
• jika beberapa aktivitas akan disebut sebagai "ekstra" atau "fitur baru" atau apa pun, rapat singkat diatur untuk menilai aktivitas tersebut.

2) tonggak & versi Saya suka ini, Anda dapat dengan mudah melacak status setiap rilis dan kapan saja Anda dapat mengunduh paket yang lebih lama, yaitu untuk menguji bug yang diajukan oleh klien.

3) fungsi "simpan" pada tab "masalah": penghemat waktu besar lainnya, saya memiliki kueri berbeda yang disimpan untuk banyak tugas pelaporan sehari-hari dan hanya itu yang saya butuhkan.

4) integrasi versi, yaitu menggunakan "# 123" di komentar akan membuat tautan ke masalah yang sesuai: cukup pintar!

Kami menggunakan Redmine secara ekstensif di sistem kami. Kami bahkan telah menyiapkan proyek "Penjualan" untuk digunakan tim penjualan kami sebagai CRM. Kami memiliki banyak bidang khusus dalam proyek ini, dan itu menggantikan SugarCRM yang kami gunakan sebelumnya.

Dalam sistem kami, kami memiliki proyek untuk perangkat lunak Server dan Klien. Proyek server dipecah menjadi submodul, berdasarkan bagaimana saya menyusun sistem dan sub-repositori, karena Redmine menyukai repo terpisah per proyek.

Kami menggunakan, seperti yang diperhatikan orang lain, kode #nnn dalam pesan commit ke tiket referensi. Yang keren adalah itu tidak perlu menjadi tiket dalam proyek yang sama. Dengan demikian, tiket penjualan dapat diblokir oleh masalah bug, atau permintaan dukungan.

Kami baru saja mulai menggunakan Dokumen untuk agenda / notulen rapat. Kami menggunakan Versi untuk mengelompokkan ke dalam rilis, baik pada klien maupun server.

Untuk mencoba menggunakan plugin Redmine Time Tracker untuk melacak waktu, tetapi saya selalu lupa mengklik mulai atau akhir. Kami mendapatkan email harian tentang masalah yang belum tersentuh dalam beberapa waktu (Saya pikir Redmine Merengek), dan yang memiliki tanggal jatuh tempo di masa lalu atau dekat (Pengingat Lanjutan).

Email dukungan langsung masuk ke proyek Dukungan kami, dan jika pengimporan email sedikit lebih kuat (terkadang tidak membuat tiket baru dengan benar jika baris Proyek: disertakan dalam email), kami akan meminta pertanyaan situs web secara otomatis menghasilkan tiket Penjualan . Karena itu, kami hanya perlu memantau tiket Dukungan, dan memindahkannya ke Penjualan jika berlaku.

Hal-hal yang ingin saya lakukan:

• Miliki hubungan antara sistem kami dan redmine, sehingga tiket dapat dikaitkan dengan pengguna atau perusahaan di sistem kami. Juga, agar kami dapat menghasilkan perusahaan baru dari tiket Penjualan di titik yang relevan. Ini hanya mengharuskan saya melakukan beberapa pekerjaan.
• Memiliki hubungan antara perangkat lunak pelacakan kesalahan kami (penjaga) dan redmine, sehingga kesalahan server menghasilkan tiket redmine. Sekali lagi, dapat dipecahkan dengan teknologi saat ini.
• Miliki klien desktop untuk redmine. Server ada di dalam LAN kita, tetapi bisa memiliki cara yang lebih fleksibel untuk mengakses data selain halaman web akan sangat bagus. Ini bukan berarti bahwa ada sesuatu yang saya tidak bisa lakukan di antarmuka web redmine, tetapi sesuatu seperti Things.app adalah begitu jauh lebih baik untuk bekerja di.
• Miliki semua dokumentasi dukungan kami dalam redmine, dan kemudian buat ke server publik. Dengan begitu, staf dukungan kami dapat mengelola dokumentasi, mengedit dengan cara yang baik, dan menerapkan perubahan ke doc-server.

Redmine sangat fantastis bagi kami sejauh ini. Kami menggunakannya sebagai antrian tiket multi-tenant / agile priority, dan telah mengikatnya ke SVN juga. Khususnya:

• Menginstal / memelihara melalui SVN sangatlah mudah (saya telah memindahkan kami dari 1.1 ke 1.2 ke 1.3 ke 1.4 melalui penggunaan svn switch https//.../branches/1.3-stable . perintah yang diikuti olehrake migrate perintah dengan hanya instalasi gem sesekali yang diperlukan di antaranya).
• Cadangan database dan file yang disimpan adalah eksekusi skrip satu baris
• Kami menyukai Time Tracker dan Spent Time plugin . Saya akan membunuh untuk klien gemuk pelacakan waktu Mac OS X untuk beberapa pengguna kantor kami, tapi itu tidak penting :)
• Kami tidak banyak menggunakan Forum, tetapi banyak menggunakan Activity dan Roadmap. Mengikat masalah ke versi tertentu adalah berkah.
• Kami juga memiliki perbedaan Klien / Server, tetapi menggunakan versi target untuk mengikat tiket untuk menentukan tujuan mana (dan telah membuka RILIS KLIEN BERIKUTNYA / RILIS SERVER BERIKUTNYA) untuk membedakan antara saat sedang dikerjakan.
• Kami mencampur metafora untuk status - kami menggunakan daftar kami yang pertama dikelompokkan berdasarkan ini ("Segera", "Ditolak", "Diblokir", "Bekerja", "Di Dek" "Daftar", "Menunggu Dibangun", "Dirilis Untuk Diuji "," Terverifikasi "," Dirilis ke Produksi "," Ditutup "," Dibatalkan).
• Kemudian, di dalam setiap grup di atas, kami memiliki daftar Prioritas yang telah diurutkan ini: ("Segera", "Prioritaskan Saya", "Desain dan Ukur Saya", "P1"… "P5", "Daftar Pantau P"). Ini ditambah di atas memungkinkan alur kerja yang mudah semua dari area masalah.
• Untuk daftar masalah dasar, kami mengurutkan berdasarkan "Prioritas", "Tugas Orang Tua", lalu "Tanggal Diperbarui" - perlu yang di tengah agar Redmine mengindentasi dengan baik jika ada tugas anak dalam pengelompokan yang sama.
• Kami menggunakan komitmen check in untuk mengikat komitmen ke masalah (yaitu, svn ci -m "This fixes #1733 @2.5, holy smoke what a weird foo bug. It is now bacon and unicorns.") - dan memindahkan masalah tersebut ke "Menunggu Dibangun" (Dulu "Terselesaikan", tetapi saya bosan menjelaskan bahwa "Terselesaikan" tidak berarti seseorang dapat berharap untuk melihatnya dirilis).

Saya pikir saya harus menyelidiki plugin Redmine-stuff-to-do. +1 Pertanyaan.

Perusahaan saya bekerja dengan pengembang perangkat lunak dan perangkat keras asal internasional. Sebelum saya bergabung dengan perusahaan, email digunakan dengan dokumen MS Word untuk menyampaikan masalah kami dan bug dengan perangkat lunak atau perangkat keras untuk meminta perbaikan. Proses ini tidak mungkin untuk melacak dan memelihara proses apapun. Saya menerapkan RedMine sebagai sarana untuk melacak bug perangkat lunak dan perangkat keras dan itu telah bekerja dengan sangat baik sejak saat itu. Ada kendala bahasa utama dengan situasi saya. Untungnya RedMine dapat menampilkan dalam bahasa Cina Sipmlified dan umpan balik telah menunjukkan bahwa sejauh ini tidak apa-apa dari pengembang saya.

Status - Saat saya menemukan masalah perangkat lunak atau perangkat keras, Statusnya "Baru" - Ketika pengembang perangkat lunak / perangkat keras saya telah melihat masalah ini dan mereka sedang mengatasinya, mereka mengubah status menjadi "Dalam Proses." Mereka dapat menggunakan% selesai jika mereka ingin dari 0 - 50. Saya meminta mereka menyetel% Selesai menjadi 50 saat mereka merasa telah menyelesaikan masalah. - Saya menentukan apakah masalah telah diperbaiki, dan saya mengubah Status menjadi "Terselesaikan" dan% selesai menjadi 100%. Ini memungkinkan saya untuk memfilter masalah <atau sama dengan 50% untuk menemukan masalah yang masih terbuka.

Prioritas - Rendah, Normal, Tinggi, Mendesak, Langsung semuanya diterjemahkan dengan baik ke dalam bahasa Mandarin.

Tanggal Jatuh Tempo - Saya menggunakan ini untuk memberi tahu saya ketika perbaikan awalnya diunggah oleh pengembang perangkat lunak saya. Mungkin perlu waktu 4-6 hari untuk menguji sesuatu dan menyelesaikan masalah. Saya suka bagan Gannt saya untuk mencerminkan daya tanggap tim perangkat lunak saya, bukan berapa lama waktu yang saya perlukan untuk menyetujui perbaikan.

Kategori - Ini selalu mencerminkan versi perangkat lunak atau perangkat keras tempat saya menemukan masalah. Saya menggunakan ini untuk melihat versi perangkat lunak mana yang memiliki jumlah bug paling banyak, dan untuk memastikan versi perangkat lunak yang lebih baru tidak mengalami regresi.

Saya memiliki semua orang yang termasuk dalam daftar pengamat RedMine untuk semua bug. Email muncul sebagai (Baru), (Terselesaikan), atau (Dalam Proses) sehingga supervisor saya, dan supervisor serta kepala teknisi dari tim yang terlibat dapat melihat email tersebut dan dengan cepat membaca kemajuan apa yang sedang dibuat. Sebagian besar orang lain yang terlibat tidak pernah masuk ke RedMine, biasanya saya satu-satunya. Email berfungsi dengan sempurna untuk memberikan pembaruan instan kepada semua orang yang satu-satunya perhatian adalah apakah kemajuan sedang dibuat atau tidak.

Seperti yang Anda sebutkan mengirim dokumen Word bolak-balik dengan QA Anda - Saya tahu perasaan ini, pernah ke sana, melakukan itu. Masalah utama bagi saya adalah: QA orang tidak suka menambahkan masalah di pelacak bug mana pun, mereka mencatatnya di editor di sebelahnya selama pengujian.

Kami menggunakan Redmine sekarang dengan addon yang bagus - Usersnap (Penafian: Kami membuat alat untuk menyelesaikan masalah ini untuk diri kami sendiri.

Usersnap sangat bagus untuk pengembang web - tambahkan ke proyek web Anda dan Anda akan mendapatkan tangkapan layar yang dilampirkan langsung ke tiket Redmine - termasuk informasi meta tentang browser yang digunakan, sistem operasi, dan sebagainya.

QA / pelanggan kami sekarang dapat memasukkan bug secara langsung di aplikasi web dan pengembang lebih mudah mereproduksi laporan bug ke Redmine.

Kami menggunakan bagian Roadmap sebagai cara yang jelas untuk menampilkan:

• bug
• fitur (yang akan menjadi referensi ke dokumen kata Anda, atau tautan ke halaman persyaratan html)
• rekonsiliasi (perbedaan antara nilai produksi dan nilai uji)
• dan seterusnya...

Itulah titik utama konsolidasi bagi kami. Sisanya digunakan terkait dengan itu (misalnya, bagian 'announce' digunakan untuk menentukan tonggak utama / tanggal rilis yang digunakan dalam peta jalan)

Selain komentar lain, saya merekomendasikan penggunaan "Stuff To Do" -Plugin (menurut saya ditulis oleh Eric Davis :) Menggunakan plugin itu memungkinkan Anda untuk menyeret-dan-melepaskan urutan masalah di beberapa proyek.

https://projects.littlestreamsoftware.com/projects/show/redmine-stuff-to-do

Kami menggunakan Versi sebagai cara untuk menentukan sprint, jadi setiap Versi adalah sprint dengan tampilan Roadmap yang memberikan ilustrasi kemajuan yang jelas. Masalah dalam sprint ditandai sebagai 'siap untuk ditinjau' setelah selesai dan kemudian ditutup ketika QA telah diverifikasi.

Kami menggunakan Versi sebagai backlog untuk masalah apa pun yang berada di luar cakupan atau kehilangan prioritas, dll.

Kami telah menggunakan Redmine selama sekitar satu tahun sekarang dan itu telah berkembang dengan sendirinya dalam banyak hal. Kami menggunakan versi untuk mengelompokkan masalah bersama-sama untuk rilis, dan kategori untuk mengelompokkan masalah menurut disiplin.

Setiap masalah melewati alur kerja yang baru> dalam proses> diselesaikan. Kemudian penguji akan menutup masalah saat senang.

Kami ingin memperbarui cara kami menggunakan Redmine, tampaknya ada begitu banyak plugin yang bagus, tetapi kami menemukan begitu banyak plugin yang rusak atau tidak dapat diinstal.

Kami menggunakan wiki secara komprehensif untuk dokumentasi pengembang.