agile planning with microsoft team foundation server
Bu Öğretici, Proje Yöneticilerinin Ekiplerinde Çalışmayı Planlamasına ve İzlemesine yardımcı olacak Microsoft TFS kullanarak Çevik Planlamanın nasıl yapılacağını açıklar:
DevOps'ta SoftwareTestingHelp.com'da yayınlanan çeşitli makaleler arasında, Microsoft TFS, AWS ve kesinlikle Ansible gibi açık kaynak araçları kullanarak Sürekli Entegrasyon ve Sürekli Teslimat açısından DevOps hakkında bazı iyi makaleler gördük.
DevOps için ön koşullardan biri, AGILE gibi belirli güçlü bir süreçtir ve bu süreçte tüm SDLC sürecine çeviklik kazandırır; burada odak alanı, yazılımı daha kısa sürüm döngüleri ve hızlı geri bildirim ile çok zamanında yayınlamaktır. Yani çevik süreç esas olarak hıza odaklanır.
Ne öğreneceksin:
Microsoft TFS 2017 Kullanarak Çevik Planlama
Bu makaledeki farklı bölümlere geçmeden önce, bazılarının farkına varmanızda fayda var. Agile'da kullanılan önemli terminolojiler. Bu terminolojiler bu makale boyunca kullanılacaktır.
Ön Koşullar: Microsoft TFS 2017
SCRUM İşlem Şablonunu Kullanarak TFS Takım Projesi Oluşturun
Öncelikle aşağıda belirtilen adımları izleyerek SCRUM şablonunu kullanarak bir TFS ekip projesi oluşturarak başlayacağız.
Microsoft TFS 2017'ye giriş yapın ve tıklayın Yeni proje.
Bir proje adı girin ve seçin Scrum şablon olarak. Tıklamak Oluşturmak.
Proje oluşturulduktan sonra üzerine tıklayarak projeye üye ekleyin. + simgesi.
Ürün İş Listesi Oluşturun
Bildiğiniz gibi, Microsoft TFS'nin, manuel test gerçekleştirme özelliği ile İş Öğeleri oluşturmaya, Proje Planlama yapmaya, Yapı Tanımları ve Sürüm Tanımları oluşturmaya yardımcı olan entegre bir ALM aracı olduğunu biliyorsunuz.
Herhangi bir Çevik planlamadan önce, tanımlayarak başlamalıyız Sprintler Bu, yapılacak iş için önceden tanımlanmış bir zaman dilimidir. Tıklamak Ayarlar -> İş ve ardından sprint'leri başlangıç ve bitiş tarihleriyle tanımlayın.
Sprint'i seçin ve başlangıç ve bitiş tarihlerini ayarlayın.
Burada, Çevik planlamanın ayrılmaz bir parçasını oluşturacak iş öğeleri oluşturmaya odaklanacağız. Öyleyse, uygulamanızın veya ürününüzün parçası olacak tüm özelliklerin öncelikli bir listesini içeren ürün biriktirme listesi oluşturarak başlayalım.
Ürün sahibi bu birikimi sürdürür ve scrum ekibinin yardımıyla belirli bir sprintte çalışmanın fizibilitesine karar verir.
Bir ürün biriktirme listesi oluşturmak için İş bölümü menüsü, Bekleme Listeleri'ni seçin.
Yeni'ye tıklayın, biriktirme listesi öğesi için bir Başlık girin ve Ekle .
Ürün İstek Listesi Öğesi, biriktirme listesine eklenir. Teorik anlamda, Ürün İş Listesi Öğesini bir Kullanıcı Hikayesi veya Değişiklik İsteği olarak düşünebilirsiniz. Normalde çoklu geliştirici görevlerinde ve test senaryolarında ayrıştırılırlar.
yazılım testi için örnek test komut dosyaları
Ayrıca önceliğe göre yeniden sipariş verebilirsiniz. Çalışma öğelerini yukarı veya aşağı sürükleyip bırakmanız yeterlidir.
İş öğesini açın ve eforu ekleyin. Burada çaba, hikaye noktalarının veya günlerin veya saatlerin proje ihtiyaçlarına göre olabilir. Efor tahmini, öğe görevlere ayrıştırıldığında eklenecektir. Bir atayın sahip 'Atanan' bölümünde ve 'Eyalet' i Onaylandı geliştirme için. Tıklamak Kaydet ve kapat.
Ardından, öğeyi Sprint 1'e sürükleyip bırakarak Sprint 1'e atayın.
Yineleme yolu, aşağıdaki resimde gösterildiği gibi öğeyi Sprint1'e değiştirir.
Öğeyi şuraya taşırken Bitti Durum, Scrum takımının bir sprintte kazandığı toplam hikaye puanı sayısını tanımlayan Velocity, sağ üstteki Velocity grafiğine tıklanarak gösterilir.
Yani özetle, yukarıdaki hız çizelgesinde gösterildiği gibi takımın Sprint 1'de 8 hikaye puanı tamamladığını söyleyebiliriz.
Kapasite planlaması
Her Sprint için, her üyenin atanan proje için çalışacağı saat sayısını tanımlayabiliriz. Her sprint için kapasite görünümü bunu tanımlar. Bu görünüm aynı zamanda her üyenin üzerinde çalıştığı Tasarım veya Geliştirme veya Raporlama vb. Faaliyetleri de yakalar.
Uygun Sprint'e tıklayın. Bu durumda, açın Sprint 1 ve şuraya git Kapasite görünümü . Aşağıda gösterildiği gibi güncelleyin.
Yukarıdaki ekran görüntüsünde Dev1 kullanıcısı 10 iş günü olan 2 haftalık sprint döneminde günde sadece 4 saat çalıştığı için. Atanan Çalışma 2 haftalık sprint dönemi için 40 saatin tamamlanması için 8 saat gerektiren bir Göreve atandığını gösterir. Bu, 4 (günlük saat) * 10 (2 hafta) = 40 saat olarak hesaplanır.
Dev2 kullanıcısı için de benzer bir hesaplama yapılır.
Görevler Oluşturma
Artık Ürün İş Listesi Öğesi veya Kullanıcı Hikayesi tanımladığımız ve ayrıca projedeki her kullanıcı için kapasite planladığımızdan, artık bunu geliştirici görevlerine ayırabiliriz. Çalışma ekranında, Sprint 1 ve ardından ürün biriktirme listesi öğesi için Görev Ekle + işaretine tıklayın.
Bunu geliştiriciye atayın ve bir değer girin saatler kalan çalışma alanı için. Kaydet ve Kapat'a tıklayın.
bilgisayarı temizlemek için en iyi yazılım
Oluşturulan görev Ürün İş Listesi Öğesine bağlıdır.
Burada Kalan çalışma alanı, bir görevi tamamlamak için kalan saat sayısıdır. Yukarıdaki örnekte alanı 8 saate ayarladığımız ve diyelim ki geliştiricinin bir gün sonunda görev üzerinde sadece 2 saatlik çalışmayı tamamladığını varsayalım, ardından kalan saat alanı 6 olarak güncellenecektir. Daha fazla iş olmadığında veya 1 saat veya daha az iş kaldığında veya 0 ile 1 saat arasında bir yerde 0.
Bu değerden TFS, Agile'daki çok kullanışlı ölçümlerden biri olan sprint için bir kapanma grafiği oluşturabilir. Yukarıdaki işlem SCRUM şablonu içindir ve Görev çalışma öğesinde Orijinal Tahmin alanına sahip değildir.
TFS ekip projesi Çevik veya CMMI işlem şablonu kullanılarak yapılandırılırsa, Orijinal Tahmin alanına girme seçeneği vardır.
Orijinal Tahmin alanını eklemek için ( Microsoft.VSTS.Scheduling.OriginalEstimate ) SCRUM işlem şablonunu kullanan Görev iş öğesi türünde özel bir alan olarak eklenmesi gerekir. Kullanabilirsiniz witadmin exportwitd , bir komut satırı seçeneğidir. Dışa aktarılan XML dosyasındaki alanı ekleyin ve ekip projesine geri aktarın.
Gelecek Sprintler
Ürün İş Listesi Öğesi veya Kullanıcı Hikayesi, öğeyi gelecekteki herhangi bir sprint'e sürükleyip bırakarak da gelecek için planlanabilir.
Görev Panosunu Kullanma
Sprint Planı yürürlükte olduğundan, artık her Görevin ilerlemesini Görev Panosu görünümünden görüntüleyebiliriz. Böylece Görev Panosu, görevlerin ve durumlarının görsel bir akışını sağlar. Bu yüzden her scrum toplantısında, üyelere atanan her görevin durumuna bakabilirsiniz.
Tamamlanması gereken kalan toplam işin özetini de görüntüleyebilirsiniz.
Durumu ve ilerlemeyi izlemek çok önemlidir ve görev panosu aracılığıyla yapılabilir. Tıkla Pano görünümü Sprint için.
Bu pano çok kullanışlı bir görünümdür ve günlük standup toplantısı sırasında raporlama amacıyla kullanılabilir.
için) Görevleri atanmış geliştiriciler görevler üzerinde çalışmaya başladıysa, görevleri şuradan taşıyabilirsiniz: Yapmak devlet Devam etmekte sadece sürükle ve bırak özelliği ile durumu.
b) Dev2 kullanıcısı için görevin kalan çalışma saatlerini 8 saatten 5 saate kadar değiştirin. Devam Eden görev saatleri buna göre güncellenecektir.
c) Burndown grafiği, sağ üst köşeye tıklanarak otomatik olarak güncellenir.
d) Şimdi görevi sürükleyip bırakarak Dev2'ye atanan görevi kapatın. Bitti durum. Bu görev için kalan çalışma saatleri otomatik olarak 0'a düşürülür ve burndown grafiği de güncellenir.
Sprint İncelemesi ve Retrospektif
Eh, iş şimdi bitti ve sprint zaman çerçevesi bitti. Takım artık rahatlama veya mola verme zamanının geldiğini düşünüyor mu? Kesinlikle büyük bir HAYIR. Şimdi gözden geçirme ve geriye dönük olarak SCRUM yaşam döngüsünün çok önemli kısmını tartışma zamanı.
Sprint incelemesi, teslimatlara odaklanır, DONE ürün birikimi öğelerini gözden geçirir ve müşterilere bir demo sağlar. Ayrıca, hangi ürün iş yığını öğelerinin yapılmadığını ve neden yapılmadığını tartışmak ve en önemlisi müşterilerden geri bildirim almak ve bunları gelecekteki sprintler için planlamak çok önemlidir. Sprint incelemesi normalde ürün sahibi, geliştirme ekibi ve müşteriler arasında yapılır.
Sprint retrospektifi, neyin iyi gittiği neyin gitmediği gibi sürecin yönlerine odaklanır. Bu nedenle, süreç ve kişiler hakkında da geri bildirim almanız gerekecektir. Bu, Çevik yaşam döngüsünün çok önemli bir yönü olduğundan, daha fazla bilgi edinebilirsiniz. retrospektifler.
Bu nedenle, her sprintte bitmemiş işlerin olması çok olasıdır. Bu senaryoda, PBI’ları / Görevleri Ürün İş Listesine veya Ürün Sahibi’nin karar vereceği bir sonraki Sprint’e taşıyın.
Ama şimdilik, incelemeleri ve geçmişe dönük belgeleri nerede saklıyoruz? Bunları çalışma öğesi tartışmasının bir parçası olarak kaydedebilir veya geriye dönük eylem noktaları ve geri bildirimleri tutmak için yeni bir çalışma öğesi oluşturabilirsiniz.
Sonuç
Bu makalede, bir ALM aracı olarak Microsoft Team Foundation Server'ın Agile Scrum sürecini takiben uygulamanız üzerinde çalışmaya başlamanın hızlı ve düzgün bir yolunu nasıl sağladığını gördük.
Agile SCRUM sürecini takip eden tüm ekiplerin, ekiplerinin çalışmasını düzgün bir şekilde planlamak ve yönetmek için aşağıdaki yönleri tanımlaması ve oluşturması gerektiğinden emin olmalıyız.
- Microsoft TFS'de uygun SCRUM işlem şablonunu kullanın
- Ürün biriktirme listeleri oluşturun
- Sprint programını ve takım kapasitesini belirleme
- Sprint iş yığını için öğe seçme
- PBI’ları veya Kullanıcı Hikayelerini Görevlere Ayrıştırma
- İlerlemeyi izlemek için Burndown grafiklerini kullanın
- İlerlemeyi izlemek için Görev Panosunu kullanmak çok önemli
- Son olarak, etkili bir sprint incelemesi ve geçmişe yönelik gerçekleştirin
Önerilen Kaynaklar
- Agile Test Dünyasında Nasıl İyi Bir Takım Mentoru, Koçu ve Gerçek Bir Takım Savunucusu Olunur? - İlham
- Çevik ve Scrum Terminolojisi: Çevik / Scrum Kavramları İçin Bir Sözlük
- Planlama Poker ile Çevik Tahmin Süreci Nasıl Kolaylaştırılır
- Testte Çevik Metodoloji İçin Modern Test İlkeleri
- Kendi Kendine Yeterli Scrum Takımları: Kendi Kendine Yeterli Bir Takım Nasıl Oluşturulur?
- Çevik Retrospektif Toplantılar - Neden Gereklidir ve Yürütmenin Bazı Eğlenceli Yolları
- Çevik Sürece Başarılı Geçiş için Çevik Test Zihniyetini Geliştirmeye Doğru 4 Adım
- ISTQB Foundation Sınav Formatı ve Bildirileri Çözme Yönergeleri