Redmine en iyi uygulamaları [kapalı]

Redmine proje yönetimi sürecinizde hangi ipuçlarını ve "standartları" kullanıyorsunuz?

Paylaşabileceğiniz standart bir wiki ekleme şablonunuz veya bug özellikleri görevlerini ve destek sorunlarını kullanarak bir projede çalışmak için standart bir yolunuz var mı?

Sorunların ve güncellemelerin Redmine'e e-postayla gönderilmesine izin veriyor musunuz? Forumları kullanıyor musunuz? SVN deposunu kullanıyor musunuz? Görev listelerinde çalışmak için Mylyn'i tutulmada kullanıyor musunuz?

Bölümümüzü sürüklemeye çalışıyorum. e-postayla gönderilen Word belgeleri yerine bazı web tabanlı PM'ye, ardından tüm rakip güncellemelerde ve projelerde nasıl KG ve Dağıtılacağını açıklayan Word belgeleri, böylece bir şeyi düzeltmem gerektiğinde kimse bulamaz nasıl çalıştığına dair herhangi bir belge.

Bir üretim şirketi ailesi için dahili uygulamalar geliştiriyor ve sürdürüyorum. Bu yorumun yapıldığı zaman itibariyle, BT ekibindeki tek geliştirici / analist benim. Ekonomik durgunluğun en kötü döneminde proje taleplerim patladı. Bu nedenle benim proje VE sorun birikimim oldukça kullanışsız. Şu anda ekibi genişletmek için yeniden yapılanma sürecindeyiz.

Redmine'i kafamı düz tutmak (mümkün olduğu ölçüde), kullanıcılarımı uzak tutmak ve umarım gelecekte yeni personelin çok fazla el ele tutuşmasını önlemek için nasıl kullandığım.

• TortoiseSVN ve uygun bir şekilde adlandırılan Tortoise-Redmine eklentisiyle kaynak kontrolü için Subversion kullanıyorum . Bir taahhütten sonra Redmine projesindeki Depoyu yenilemek, konuyla ilgili revizyonu gösteren sorunu birbirine bağlar ve e-posta bildirimi yoluyla paydaşlarımı günceller.
• Proje açıklamasını, projenin amacını, kapsamını ve yaşam döngüsü aşamasını dahil olmayanlara iletmenin bir yolu olarak görüyorum. Bu şekilde, kullanıcılarım tabağımda ne olduğunu ve büfede hâlâ ne olduğunu ve uzaktan baktığım şeyi biliyorlar.
• İzin setlerim için, bir dizi izin setinden fazlasını belirten belirli rol adları kullanıyorum - yine bir dokümantasyon aracı olarak. Görevlerim şunları içerir: Proje Yöneticisi, Proje Ekibi Üyesi, Sahip, Birincil Kullanıcı, İkincil Kullanıcı, Gözlemci, Overlord (patronlarım için ... hem eğlenceli hem de inkar edilemez şekilde doğru).
• Hangisinin uygun olduğunu düşündüğüme bağlı olarak dokümantasyon için Wiki ve Dokümanları kullanıyorum.
• Sürümler benim için pek işe yaramaz, bu yüzden bunu planlı sürümler için kullanmak yerine, ilgili sorunları sprintler halinde gruplamak için kullanıyorum.
• Sorunlarımdaki Hedef Sürümleri toplu olarak düzenlemeden önce yukarıda belirtilen sprintleri düzenlemek / yeniden düzenlemek için Eric Davis'in harika Şeyler-Yapılacaklar eklentisini kullanıyorum. Bu aynı zamanda paydaşlarımın ne üzerinde çalıştığımı ve ilgi alanlarına nasıl öncelik verdiğimi (iyi ya da kötü) bilmelerini sağlar.
• Kullanıcı etkileşimini teşvik etmek için uygulamalarımın Yardım menülerine Redmine projesine bağlantılar ekledim. "Hakkında" kutusu ayrıca Redmine projesine bir bağlantı içerir.

Gelecek planları

• Redmine entegrasyonu için Visual Studio uzantımı bir noktada bitirmeyi umuyorum.
• Uygulamamı Redmine projesiyle gevşek bir şekilde birleştirmek için bir kod kitaplığı oluşturun: hata gönderimini otomatikleştirin, abone paydaşları sistem tepsisinden uyarın, Redmine'in REST API'si tarafından yönlendirilen yeniden kullanılabilir etkileşimli Yardım menüsü vb. (Belki de belgelerin bölümlerini Wiki ile otomatikleştirin?)

Bir (benim) geliştirme işini yürüten serbest çalışan bir Ruby ve Redmine web geliştiricisiyim. Yani Redmine'im oldukça hafif ve müşteri odaklı olacak şekilde ayarlandı. Redmine'im ayrıca Açık Kaynak projelerimi barındırmak için çifte görev yapıyor.

Yeni sorunların ve güncellemelerin e-postayla gönderilmesine izin veriyorum ve e-posta bağlantılı kullanıcılar (veya her zaman iPhone'larını kullanan kullanıcılar) için harika çalışıyor.

Depo görünümünü git depolarıyla kullanıyorum ve harika çalışıyor. Her girişte soruna #nnn ile atıfta bulunuyorum, böylece asıl sorun sayfası özelliği uygulamak için tüm taahhütleri gösterecektir.

Forumların yetersiz kullanıldığını buldum. Bence biraz e-posta entegrasyonu olsaydı, daha yararlı olurdu.

Aşağıdaki uygulamaları faydalı bulduk:

1) "Sorun" ve "Destek" izleyicisini gizleyin ve her şeyi bir hata olarak kaydedin :

• geliştiriciler, test uzmanları ve yönetim için zaman kazandıran;
• bazı etkinlikler "ekstra" veya "yeni özellik" veya başka bir şey olarak faturalandırılacaksa, bunları değerlendirmek için hızlı toplantılar düzenlenir.

2) kilometre taşları ve sürümler Bunu seviyorum, her sürümün durumunu kolayca takip edebilir ve istediğiniz zaman eski bir paketi indirebilirsiniz, yani müşteri tarafından dosyalanmış bir hatayı test etmek için.

3) "sorunlar" sekmesinde "kaydet" işlevi: başka bir büyük zaman kazandıran, birçok günlük raporlama görevi için kaydedilmiş farklı sorgularım var ve tek ihtiyacım olan bu.

4) sürüm entegrasyonu, yani yorumlarda "# 123" kullanmak, ilgili soruna bir bağlantı oluşturur: basitçe akıllıca!

Redmine'i sistemimizde yoğun olarak kullanıyoruz. Satış ekibimizin CRM olarak kullanması için bir "Satış" projesi bile oluşturduk. Bu projede bir yığın özel alanımız var ve daha önce kullandığımız SugarCRM'in yerini alıyor.

Sistemimiz içerisinde Sunucu ve İstemci yazılımları için projelerimiz bulunmaktadır. Redmine proje başına ayrı bir depoyu sevdiğinden, sunucu projesi, sistemi ve alt depoları nasıl yapılandırdığıma bağlı olarak alt modüllere ayrılmıştır.

Başkalarının da belirttiği gibi, biletleri referans almak için commit mesajlarında #nnn kodlarını kullanıyoruz. Harika olan, aynı projede bilet olması gerekmemesi. Bu nedenle, bir satış bileti bir hata sorunu veya bir destek talebi ile engellenebilir.

Belgeleri gündem / toplantı tutanakları için kullanmaya yeni başladık. Hem istemcide hem de sunucuda sürümleri gruplamak için Sürümleri kullanıyoruz.

Zamanı izlemek için Redmine Time Tracker eklentisini kullanmayı denemek için, ancak her zaman başlat veya son'u tıklamayı unutuyorum. Bir süredir dokunulmayan (Redmine Whining, sanırım) ve son tarihi geçmiş veya yakın gelecekte olan konular hakkında günlük e-postalar alıyoruz (Gelişmiş Hatırlatma).

Destek e-postaları doğrudan Destek projemize gider ve e-posta içe aktarma işlemi biraz daha sağlam olsaydı (bazen e-postaya Proje: satırı eklenmişse yeni biletler düzgün şekilde oluşturulmaz), web sitesi sorgularının otomatik olarak Satış biletleri oluşturmasını isterdik. . Olduğu gibi, Destek biletlerini izlememiz ve varsa Satış'a taşımamız gerekiyor.

Yapmak istediğim şeyler:

• Sistemimiz ile redmine arasında ilişkiler kurun, böylece biletler sistemimizdeki bir kullanıcı veya şirket ile ilişkilendirilebilir. Ayrıca, ilgili noktada Satış biletinden yeni bir şirket oluşturabilmemiz için. Bu sadece biraz iş yapmamı gerektiriyor.
• Hata izleme yazılımımız (nöbetçi) ve redmine arasında bir ilişki kurun, böylece sunucu hataları bir redmine bileti oluşturur. Yine güncel teknoloji ile çözülebilir.
• Redmine için bir masaüstü istemciniz olsun. Sunucu, LAN'ımızın içindedir, ancak web sayfası dışındaki verilere erişmek için daha esnek bir yola sahip olmak harika olurdu. Redmine web arayüzünde gerçekten yapamayacağım bir şey olmadığı için, Things.app gibi bir şey çalışmak için çok daha hoş.
• Destek belgelerimizin tamamını redmine içinde bulundurun ve ardından halka açık bir sunucuda oluşturun. Bu şekilde, destek ekibimiz belgeleri koruyabilir, güzel bir şekilde düzenleyebilir ve değişiklikleri doc-server'a dağıtabilir.

Redmine şimdiye kadar bizim için harika oldu. Bunu çok kiracılı bir biletleme / çevik önceliklendirme kuyruğu olarak kullanıyoruz ve bunu SVN'ye de bağladık. Özellikle:

• SVN üzerinden kurulum / bakım yapmak çok kolay oldu (Bizi 1.1'den 1.2'ye 1.3'ten 1.4'e, svn switch https//.../branches/1.3-stable .komutların kullanılması ve ardından rake migratesadece arada sırada gerekli olan gem kurulumlarının gerekli olduğu komutların kullanılmasıyla taşıdım).
• Veritabanının ve depolanan dosyaların yedekleri tek satırlık bir komut dosyası yürütmedir
• Time Tracker ve Spent Time eklentilerini seviyoruz . Bazı ofis kullanıcılarımız için bir Mac OS X zaman takibi fat istemcisi için öldürürdüm, ama asıl mesele bu :)
• Forumları çok kullanmıyoruz, ancak ağırlıklı olarak Aktivite ve Yol Haritası kullanıyoruz. Sorunları belirli sürümlere bağlamak bir nimettir.
• Ayrıca İstemci / Sunucu ayrımlarımız da var, ancak üzerinde çalışılırken arasında ayrım yapmak için hangisinin nereye gideceğini (ve açık uçlu SONRAKİ MÜŞTERİ SUNUCUSU / SONRAKİ SUNUCU SUNUCUSU) belirtmek için biletleri bağlamak için hedef sürümü kullanıyoruz.
• Durumlar için metaforları karıştırıyoruz - önce bunlara göre gruplandırılmış listelerimizi kullanıyoruz ("Hemen", "Reddedildi", "Engellendi", "Çalışıyor", "Güverte" "Liste", "Oluşturulmayı Bekliyor", "Test Etmek İçin Yayınlandı" "," Doğrulandı "," Üretime Çıktı "," Kapatıldı "," İptal Edildi).
• Ardından, yukarıdaki her grupta, şu sıralı Öncelikler listesine sahibiz: ("Hemen", "Bana Öncelik Ver", "Tasarım Ve Boyutlandır", "P1"… "P5", "P-İzleme Listesi"). Bu artı yukarıdakiler, tüm sorunlar alanından kolay iş akışına izin verir.
• Temel sorunlar listesi için, "Öncelik", "Ana Görev" ve ardından "Güncellenmiş Tarih" e göre sıralama yaparız - aynı gruplamada bir alt görev olması durumunda Redmine'nin güzel bir şekilde girintilemesi için ortadaki tarihe ihtiyaç duyarız.
• İşlemleri sorunlara bağlamak için iade taahhütlerini kullanıyoruz (yani, svn ci -m "This fixes #1733 @2.5, holy smoke what a weird foo bug. It is now bacon and unicorns.") - ve bu sorunu "Oluşturmayı Bekliyor" a taşımasını sağlıyoruz (Bu önceden "Çözüldü" idi, ancak "Çözüldü" ifadesinin birisinin bunu yapabileceği anlamına gelmediğini açıklamaktan yoruldum henüz piyasaya sürülmesini bekliyoruz).

Redmine-to-do eklentisini araştırmam gerekeceğini düşünüyorum. +1 Soru.

Şirketim uluslararası kökenli yazılım ve donanım geliştiricilerle çalışıyor. Şirkete katılmadan önce, bir düzeltme istemek için yazılım veya donanımla ilgili sorunlarımızı ve hataları iletmek için MS Word belgeleriyle birlikte e-posta kullanılıyordu. Bu süreç, herhangi bir süreci takip etmek ve sürdürmek imkansızdı. RedMine'ı yazılım ve donanım hatalarını izlemek için bir araç olarak uyguladım ve o zamandan beri çok iyi çalışıyor. Durumumda büyük bir dil engeli var. Neyse ki RedMine, Sipmlified Çince dilinde görüntüleyebiliyor ve geri bildirimler, bunun geliştiricilerimden çok uzakta olduğunu gösterdi.

Durum - Bir yazılım veya donanım sorunu bulduğumda Durum "Yeni" - Yazılım / donanım geliştiricilerim bu sorunu gördüklerinde ve üzerinde çalıştıklarında durumu "Devam Ediyor" olarak değiştirirler. 0 - 50 arasında istedikleri takdirde yapılan% 'i kullanabilirler. Sorunu çözdüklerini düşündüklerinde% Bitti'yi 50 olarak ayarlamalarını sağladım. - Sorunun çözülüp çözülmediğini belirlerim ve Durumu "Çözüldü" ve% tamamlandı olarak değiştiririm.% 100. Bu, hala açık olan sorunları bulmak için <veya% 50'ye eşit sorunları filtrelememe izin veriyor.

Öncelik - Düşük, Normal, Yüksek, Acil, Hemen tümü Çince'ye iyi tercüme edilir.

Son Tarih - Bunu, yazılım geliştiricilerim tarafından düzeltmenin ilk olarak ne zaman yüklendiğini belirtmek için kullanıyorum. Bir şeyi test etmem ve sorunu kapatmam 4-6 gün sürebilir. Gannt grafiğimin, düzeltmeyi onaylamamın ne kadar sürdüğünü değil, yazılım ekibimin duyarlılığını yansıtmasını seviyorum.

Kategori - Bu her zaman sorunu bulduğum yazılım veya donanım sürümünü yansıtır. Bunu, hangi yazılım sürümünün en fazla hataya sahip olduğunu görmek ve yazılımın yeni sürümlerinin gerilemeye maruz kalmamasını sağlamak için kullanıyorum.

Tüm hatalar için RedMine izleyici listesine herkesi dahil ettim. E-posta (Yeni), (Çözüldü) veya (Devam Ediyor) olarak gelir, böylece amirlerim ve dahil olan ekiplerin amirleri ve baş mühendisleri e-postayı görebilir ve şu anda hangi ilerlemeyi hızlı bir şekilde okuyabilir. Dahil olan diğer insanların çoğu RedMine'a hiç giriş yapmıyor, genellikle tek kişi benim. E-postalar, tek endişesi ilerleme olup olmadığı olan herkese anında güncelleme sağlamak için mükemmel bir şekilde hizmet ediyor.

QA ile Word belgelerini ileri geri göndermekten bahsettiğiniz gibi - Bu duyguyu biliyorum, oradaydı, yaptım. Benim için ana sorun şuydu: QA çalışanları herhangi bir hata izleyiciye sorun eklemekten hoşlanmazlar, test sırasında yanlarındaki bir düzenleyicide bunları not ederler.

Şimdi güzel bir eklenti ile Redmine kullanıyoruz - Usersnap (Sorumluluk Reddi: Bu sorunu kendimiz için çözmek için aracı geliştirdik.

Usersnap web geliştiricileri için harikadır - web projenize ekleyin ve kullanılan tarayıcı, işletim sistemi vb. Hakkında meta bilgiler dahil olmak üzere doğrudan Redmine biletlerine eklenmiş ekran görüntüleri alacaksınız.

QA'larımız / müşterilerimiz artık hataları doğrudan web uygulamasına girebilir ve geliştiriciler, hata raporlarını Redmine'de yeniden üretmeyi kolaylaştırır.

Yol Haritası bölümünü, aşağıdakileri göstermenin net bir yolu olarak kullanıyoruz:

• böcekler
• özellikler (kelime belgenize referanslar veya html gereksinim sayfalarına bağlantı olabilir)
• mutabakatlar (üretim değerleri ile test değerleri arasındaki farklar)
• ve bunun gibi...

Bizim için konsolidasyonun ana noktası budur. Geri kalanı bununla ilişkili olarak kullanılır (örneğin, 'duyuru' bölümü yol haritasında kullanılan ana kilometre taşı / çıkış tarihlerini tanımlamak için kullanılır)

Diğer yorumlara ek olarak, "Yapılacak Şeyler" -Plugin (Eric Davis tarafından yazılmıştır düşünüyorum :) Bu eklentiyi kullanmak, birden çok projede sorunların sırasını sürükleyip bırakmanıza olanak tanır.

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

Sürümleri sprintleri tanımlamanın bir yolu olarak kullanıyoruz, bu nedenle her Sürüm, ilerlemenin net bir resmini veren Yol Haritası görünümüne sahip bir sprinttir. Sprintlerdeki sorunlar tamamlandığında "incelemeye hazır" olarak işaretlenir ve ardından QA doğrulandığında kapatılır.

Kapsam dışında kalan veya önceliğini yitiren vb. Sorunlar için iş yığını olarak bir Sürüm kullanıyoruz.

Redmine'i yaklaşık bir yıldır kullanıyoruz ve birçok yönden kendi kendine gelişti. Bir sürüm için sorunları birlikte gruplamak için sürümleri ve disiplinlere göre gruplandırmak için kategorileri kullanırız.

Her sorun yeni> devam eden> çözülmüş bir iş akışından geçer. Ardından test uzmanı mutlu olduğunda sorunu kapatır.

Redmine kullanma şeklimizi güncellemeyi çok isteriz, pek çok harika eklenti var gibi görünüyor, ancak pek çoğunun bozuk olduğunu veya yüklenmediğini görüyoruz.

Wiki'yi geliştirici belgeleri için kapsamlı bir şekilde kullanıyoruz.