Konuya dalmadan önce söyleyelim, TFS üzerindeki en büyük yapı bir Takım Projesi (Team Project)'dir. Bir Takım Projesinin kaynak kod kontrol sisteminde kendine ait bir alanı, WIT sisteminde kendine ait form tipleri, sharepoint üzerinde kendi proje sitesi ve kendi rapor tipleri vardır. Tüm bunlar Süreç Şablonu (Process Template) adı verilen bir şablon temel alınarak hazırlanır ama bu da ileride detaylarına gireceğimiz bir başlık.
Ne diyorduk? ... hah... work item...
Dediğim gibi her bir projenin kendi ait form tipleri vardır ve Work Item (WI) bunlara verilen genel isimdir. WI dediğimiz; metin alanlardan, çoktan seçmeli listelerden, sekmelerden vs oluşan elektronik bir formdur. Kullandığınız süreç şablonuna göre tipleri farklılık gösterir. Örneğin TFS içerisinde hazır olarak gelen CMMI şablonunu kullanırsanız Gereksinim (Requirement), Değişiklik İsteği (Change Request), Hata (Bug), Görev (Task) gibi WI tipleri ile karşılaşırsınız. Her birinin kendilerine özgü alanları ve ortak alanları vardır. Kabaca şöyle birşeye benzer...
TFS Power Tools paketini indirirseniz mevcut form tipleri üzerinde değişiklik yapabileceğiniz bir editöre kavuşursunuz. Hatta kendi WI tiplerinizi tanımlayabilirsiniz.
WI'lar AreaPath ve IterationPath alanlarını kullanarak alt gruplara ayırılabilir. Örneğin projelerin, modüllerin, versiyonların vs işlerini ayrı takip etmek için bu alanlar kullanılabilir. Bu alanlara ağaç yapısında tanım yapmak mümkündür.
WI'lar kişilerin üzerine atanır. Elden ele gezebilir. TFS üzerine WI atılan kişiye otomatik e-posta gönderir. Kendinize ya da bir başkasına atanmış olan WI'ları listeleyebilirsiniz. Kişilerin üzerindeki işleri takip edebilirsiniz.
Her bir WI'ın oluşturulduğu günden son haline kadar olan tarihçesi TFS tarafından saklanır ve görüntülenir. Bu sayede herhangi bir WI'ı hangi tarihte kim oluşturmuş, kime atanmış, hangi alanlarına neler yazmış, kimler ne değişiklikler yapmış vs. gibi bilgilere ulaşmak mümkündür.
Ayrıca WI 'lar ilişkiler konusunda da yeteneklidir. Bir WI'ın ekine herhangi bir tipte bir dosya iliştirmek mümkündür, Kaynak kod kontrol sisteminden bir changeset ile ilişkilendirmek ya da diğer bir WI ile ilişkilendirmek mümkündür. Hele TFS 2010 ile çalışma şansına erişen mutlu kitleden bir bireyseniz WI lar arasındaki ilişkilere tip bile tanımlayabilir durumdasınız demektir ama bu ağız sulandıran detaya şimdi girmeyelim.
Parça parça anlattıklarımızı toplarlayıp başladığımız yere dönecek olursak, WI 'ları işlerinizi takip etmek için kullanırsınız. Örneğin bir projede yapılacak işleri gereksinim tipinde WI'lar olarak sisteme alırsınız. Bunlarla ilgili açıklamaları üzerine yazarsınız. Analizi derinleştirecek detaylı dosyaları bunların ekine iliştirirsiniz.
Daha sonra bunları ekibinize paylaştırmak için alt görevlere böler ve her bir görev için bir WI açıp ilgili kişinin üzerine atarsınız. Tabii ki alt görevleri ana gereksinim maddesiyle eşlersiniz. Onlar da görevlerini bitirdikçe bu kayıtları kapatırlar.
Nasıl ? İyi gidiyor değil mi? Dahası var...
Proje sırasında gelen değişiklik isteklerini de birer WI yapar ve gereksinimler ile ilişkili olarak kaydedersiniz. Neyin değişmesinin istendiğini ve bunun analizini yazarsınız.
Yazılım teste çıktığında dönen hataları da bu gereksinimle ya da değişiklik isteğiyle ya da görevlerle ilişkili olarak sisteme girersiniz. Hata mesajını, tanımını, varsa ekran görüntülerini hata kaydına girersiniz.
En güzelini en sona sakladım.
WI'ları changeset'ler ile ilişkilendirmek mümkün demiştik ya. İşte bunu da herhangi bir changeset'i check-in ederken ilişkili bir WI seçerek yaparsınız.
Bütün bunları yaptığınız zaman projenin herhangi bir anında proje kapsamında neler varmış, kimlere paylaştırılmış, ne kadarı bitmiş, daha yapılacak kimin üzerinde ne kadar iş var, hangi işler için ne değişiklik istenmiş, ne için ne kadar kod yazılmış, nasıl test edilmiş, hangi koddan ne kadar hata çıkmış, hataları düzeltmek için ne değişiklikler yapılmış gibi ... gibi ... gibi ... daha bir çok soruya cevap verebilir durumda olursunuz.
Bu sayede proje ilerleme raporundan tutun da gereksinim toplama sürecinin etkinliğine, modüllere göre hata yoğunluğundan gereksinim/test kapsama raporuna kadar her raporu hazırlayacak altyapınız olur.
Ya da tam ters yönden bakacak olursak kodlara altan üstten bakıp da neden yazıldığını anlayamadığınız o iki satırın başında saçlarınızı yolarken TFS'in "Annotate" komutunu kullanarak her bir dosyadaki her bir satır kodun hangi tarihte kim tarafından ne için yazıldığını, neden değiştiğini, nasıl test edildiğini vs. görebilirsiniz.
Sırada: Doküman Yönetimi ...
