MSF Takım modellerinde değişiklikler

MSF’e neler oluyor? Herşeyden önce MSF’te değişiklik görmek kimseyi şaşırtmamalı, çünkü MSF canlı bir yapıdır, ve zaman içinde değişikliklere tabi olması normaldir. Ancak V3’ten sonraki değişiklikler doğal mı yoksa zorlama mı burada bazı soru işaretleri doğmaktadır.
 
Bu soru işaretlerinin ardında yatan temel neden, MSF’in aniden ve radikal bir biçimde değişirken bu değişimi ağırlıklı olarak VSTS’e uymak için yaşıyor olmasıdır. İşte bu pek de MSF’ten beklenen türde bir gelişme değil!
 
MSF’teki tüm değişiklikleri konuşmaya bir blog girişi yetmez. Tamamına da vakıf değilim zaten, daha çok işime yarayan şeyleri ayıklamaya çalışıyorum. Bu arada VSTS ile birlikte gelen şeylere nazaran da farklılıklardan bahsediliyor MSF 4 için. MSF v4 terminolojisinde ilk defa çekirdek ve yaklaşım (örneklem) ifadeleri yer alıyor. Ürün ve süreç birbirine yaklaşırken MSF’in içinden çıkmak zorlaşıyor.
 
MSF v3 (v2’de de aynıdır) Program Management rolünden bahseder. Elimde bu rolü ikiye bölüp Architect ve Project Management olarak gösteren sunular var, burada anlatılmak istenen, PgM, mimari ve proje yönetimini üstlenen roldür. Bu yaklaşım kalabalık takımlarda sorunsuz çalışabilir, ancak program management rolünü bir kişi üstlendiğinde burada bir çelişki ile karşı karşıya kalırız.
 
Bu sorun genellenen bir sorun, tabii ki istisnaları olacaktır, ancak ben şu ana kadar rastlamadım. Yazılım mimarisi gayet teknik bir iştir, yazılım geçmişi, tercihen uzun ve derin bir yazılım geçmişi ister; diğer taraftan proje yönetimi (takvim ve kaynakların yönetimi anlamında) gayet yönetseldir. Genellikle insanlar, kendi geçmişlerine ve ilgi alanlarına uygun olarak bu konulardan sadece biriyle yakından ilgilenmeyi tercih ederler. Sonuç olarak projelerde mimari ya da proje yönetimi disiplini aksar.
 
MSF v4, doğru olarak bu sorunu görmüş, biraz da proje yönetimi disiplininin savunucularından (PMI!!) proje yöneticisi nerede baskısı altında kalarak bu rolü bölmüştür. Bazı VSTS dokümanlarında bu rol project manager ve architect olarak bölünse de Microsoft Solutions Framework Essentials – Building Successful Technology Solutions (MS Press) isimli kitabın yazarı Michael S. V. Turner, ki MS Services’te kıdemli yönetici, program management ifadesini korumuş. MSF v4 ile ilgili tüm alıntılar ve referans ağırlıklı olarak bu kitap, eğer VSTS/TFS dokümantasyonu vs olarak aksi belirtilmemişse.
 
Ben bu takım modelinde bazı değişiklikler yapılması gereğini düşünüyorum, özellikle de proje tiplerine dayalı olarak. Şu anda da bundan bahsediyor ve çeşitli şekillerde hem tavsiye ediyorum hem de uyguluyorum. Ama bunu da daha sonraki bir blog girişine bırakalım.. Şimdilik bu kadar yeter..
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