MSF V4 vs V3

MSF V4 çıkalı bayağı bir zaman oldu. İlk başlarda tamamen VSTS ile uyum ön plandayken, MS Press’ten yayınlanan Michael Turner’ın MSF Essentials isimli kitabı ile VSTS dışında da MSF’in devam edebileceği belli oldu. Herşeyden önce, VSTS ile uyum MSF’ten çok şey götürdü, çünkü aslında MSF asla sadece bir ürün ile uygulanabilecek bir metodoloji olmadı. Sanırım aynı şeyler diğer metodolojiler için de geçerli ki, örneğin VSTS içindeki CMMI da çok havada kaldı.
 
Velhasılı kelam, VSTS içindeki haliyle değil de eski haliyle kıyaslanacak şekilde bir MSF V4’ten bahsetmek bu kitap sayesinde mümkün oldu. Aslında bu kitapla beraber MSF de ilk defa MS tarafından yayınlanmış (resmi diyebilir miyiz bilmiyorum) bir kitaba sahip oldu. Daha önce sadece eğitim materyalleri ve bazı makaleler vardı. Doğrudan refere edilebilir bir kaynağın varlığı bence olumlu bir gelişme.
 
Diğer taraftan MS’teki ciddi Scrum eğilimini de incelemek gerektiğini düşünüyorum. VSTS’in içinde MSF olarak lanse edilen birçok kavramın orjinal MSF’ten ziyade Scrum’a benzediği aşikar. Ancak bu da başka bir yazının konusu olacaktır. MSF vs Scrum gibi bir yazı yazmak için sadece MSF bilmek yetmeyecek, Scrum’ı da daha detaylı incelemek gerekecek, henüz bu seviyede miyim emin değilim. Açıkçası Scrum hakkında hala olması gerektiğinden basit yargımı koruyorum.
 
Neyse, V3 – V4 arasındaki farklara gelince; bu Turner’in kitabının ilk bölümündeki listedir. O liste üzerinden yorumluyorum. Kitabın bütünü incelenerek daha detaylı bir çalışma yapmak mümkün olmakla beraber bu aşamada Turner’ın makul bir liste yaptığını varsayarak onu kullanacağım. Yine de listeye başlamadan, apılan değişikliklerin büyük çoğunluğunun kozmetik olduğunu kolayca görebiliyorsunuz. Örneğin içeriği tamamen aynı olan kavramların sadece isimleri değişmiş. Bu tarz yeniden adlandırmalar bazen uyum bazen de iyi ifade adına doğru seçim olabiliyor, ancak V4’te sanırım ipin ucu biraz kaçmış. (Tüm isim farklarına değinmeyeceğim..)
 
Takım modelindeki roller "advocacy group" olarak adlandırılmış. Bunu doğrudan avukatlık grubu diye çevirseniz kullanımı zorlaşır, temsil grubu deseniz, onun da altından çıkış yok.. Ancak vurgu yine de faydalı olabilir, böylece aynı uzmanın birden çok rolü taşıyabileceği daha net ifade edilebilir. Takım modelinin doğrudan bir görev paylaşımı olmadığını iyi anlamak/anlatmak gerekiyor. Yine de, özellikle türkçede daha uygun bir ifadeye ihtiyaç var.
 
Takım modelinde en önemli değişiklik, V3.1 olarak adlandırılan bir takım makalede de duyurulan, Mimari (temsil) rolü, ya da Mimar rolü. Proje yönetimi (kaynak – takvim yönetimi) ve mimari tasarımın aynı rolde birleşmesi, bu rolü bölme ikmanı olmayan projelerde iki taraftan birine ağırlık verilmesi riskini ortaya çıkartıyordu. Artık bunların farklı kişiler tarafından taşınması gereğini daha kolay vurgulayabileceğiz. Rolün diğer yarısının adının program yönetimi olarak kalmasında bir sakınca yok, ancak bu MS’in bünyesindeki kullanımdan oldukça uzaklaşmış oluyor.
 
Süreç modelinin adı governance model olmuş. Moda her terimi bir ucundan yakalamak zorundasınız, yoksa çarpılırsınız! Uysa da olur uymasa da! Kilometre taşının adı bile kontrol noktası (check point) olmuş. (Bunlar Scrum mı? emin değilim, tekrar bakmak lazım, bir sonraki kontrol notkasında buluşalım..)
 
Defect, issue olmuş. Bence bu da olumsuz bir değişim, çünkü defect MSF’te bug anlamında kullanılır, yani uygunsuz bir durum, ancak issue bir sorun için kullanılır. Böylece her defect bir issue olmak zorunda değildir. Keza her issue da bir defectten kaynaklanmaz. Yani isim deyip geçmeyin.
 
Bazı ekler var:
 
Takvim oluşturma süreci (scheduling process), MSF’in takvim ve proje yönetimine uzak, teknik yaklaşımını biraz daha yönetilir bir hale sokacaktır. Eski tüfek coder’ların yerini yavaş yavaş proje yöneticileri alacak.
 
Governance track (artık phase / faz yerine track deniyor), sürecin idaresi için eklenmiş. Scrum’daki Scrum Master gibi, sürecin sürekli gözetildiği, modele uyumu ve gelişimi için takım işler konmuş. İşin zorlu yanı, bunu bir faz gibi sıraladığınız zaman pek uymuyor, o yüzden aslında bir faz (track) yerine bence bir disiplin olarak eklense (risk yönetimi, proje yönetimi vs.) daha uygun olabilirmiş. Bu kısımları daha detaylı inceleyeceğim, belki de ben yanlış değerlendiriyorum.
 
Evet, sonuçta modellerin çoğu yanlıştır, bazıları faydalı olabilir. (G. Box)
Bu yazı Yazılım mühendisliği içinde yayınlandı. Kalıcı bağlantıyı yer imlerinize ekleyin.

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Google fotoğrafı

Google hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Connecting to %s