Aşağıda, bir yazılım evi için çevik proje çalışmasındaki rol modeline benzer şekilde sorumlulukların atanmasına yönelik öneriler yer almaktadır.
I. Product Owner'a Karşı Müşteri Proje Yöneticisi
Birinci tez: Çevik süreç modeli, şirketimin müşteri proje yöneticisinin rolünü ve yetki sınırlamalarını, uygulamada genel olarak yapılandan çok daha güçlü şekilde temellendirmelidir.
Risk
Müşteri talepleri bireysel olarak uygulanır ve yazılım altyapımın temiz yapısını bozar.
Strateji
Yazılım evim ekonomik olarak hareket etmelidir. Bir müşterinin aldığı çözüm, yazılım altyapımın kullanımı aracılığıyla uygulanmalıdır. Bu altyapının genişletilmesi, her zaman kendi yazılım standardımı* göz önünde bulundurarak kademeli olarak gerçekleştirilir.
*Burada kastedilen: kurulu geliştirme ortamı, mimari kütüphaneleri, fonksiyon kütüphaneleri ve arayüze kadar uzanan – yani şimdiye kadarki geliştirme çalışmalarının sonuçlarıdır. Bunlar, insan sermayesinin yanı sıra şirketimin en önemli varlığıdır.
Müşteri sorumlum veya müşteri proje yöneticim – yazarın görüşüne göre çevik süreç modelinde yeterince temsil edilmemiştir – müşteri taleplerinin yazılımda nasıl temsil edileceğine dair önerilerini geliştirme yöneticisi veya Product Owner ile yakından koordine etmelidir.
Aksi takdirde altyapım "parçalanır", her müşteri "özel muamele" alır ve ikinci seviye destek bulgularla artık verimli çalışamaz hale gelir.
Dikkat edilmesi gerekenler
Müşteriyle, özel taleplerin yeni bir modülün tüm müşterilere teslim edilebilecek şekilde belirlenmesi konusunda mutabakat sağlanmalıdır. Yetki konsepti üzerinden modül, talep eden kişide etkinleştirilir. Diğer müşteri sorumluları fonksiyon açıklamasını satış bilgisi olarak alır ve kendi müşterileri için katma değeri değerlendirir.
II. Product Owner'a Karşı Geliştirme Ekibi*
*Çevik tarz Geliştirme Ekibi: Product Backlog'dan işleri uygulayan ve çalışır durumda artışlar (increment) sunan, kendi kendini organize eden, disiplinler arası bir ekip.
İkinci tez: "Geliştirme yöneticisi" rolü (burada odak noktası: Teknik Lider – mimari ve fonksiyon kütüphanelerinin sorumlusu) çevik süreç modelinde yeterince kesin tanımlanmamıştır.
Risk
Ekibe veya tek tek çalışanlara çok fazla özgürlük tanınır.
Strateji
Yazılım geliştirmeyi yönetmiş olan herkes bu senaryoyu bilir: Becerikli bir ekip üyesi hızlıca işini bitirir ama daha önce bilinmeyen yeni kütüphaneler eklemiştir. Genellikle çok farklı lisans koşullarına sahip açık kaynak yazılımlardır. Ücretsiz kullanım bir güncellemeyle birlikte geçersiz hale gelebilir ve maliyet hesaplamasını öngörülemez şekilde etkileyebilir. Yeni kütüphaneler ayrıca yeni, genellikle bilinmeyen zafiyetler getirir.
Dikkat edilmesi gerekenler
Üçüncü taraf yazılımların bolluğunda "kütüphane yönetimi" görevi sorumlu bir ele verilmelidir. Ekipler yalnızca onaylanmış yapı taşlarını kullanır. Yeni yapı taşları Teknik Lider'den talep edilir. Bu işi Product Owner'ın mı yoksa belirlenmiş bir paydaşın mı yapacağı ikincil önemdedir – görev açıkça tanımlanmış olmalıdır.
III. Kullanım Felsefesi & Kullanılabilirlik'e Karşı Çevik Uyarlamalar
Üçüncü tez: Bir kullanım felsefesi günümüz standartlarını karşılamalı ve tüm yazılım boyunca tutarlı şekilde uygulanmalıdır.
Risk
Farklı alanlarda farklı kullanım mantıkları: bazen bağlam menüsü, bazen dağınık düğmeler, bazen yalnızca birinci seviye destekle kullanılabilir. Hiç kimsenin egzotik kullanım felsefelerine zamanı veya kabulü yoktur.
Strateji
Kullanıcı etkileşimi için kullanılan kütüphaneler kullanılabilirlik açısından test edilmiş ve yaygın standartlara uygun olmalıdır.
Dikkat edilmesi gerekenler
Kullanım felsefesini tanımlayın! Sözde endüstri standartları Amazon, PayPal & Co. gibi sistemler tarafından şekillendirilir. Bir "müşteri yolculuğu" (deneyimsiz kişilerle kullanılabilirlik testleri) düzenleyin. Geliştiricileri, yaratıcı ama egzotik kendi geliştirmelerinden kaçınmak için yaygın standartlarla ilgilenmeye zorlayın.
IV. İstisna Yönetimi & Kararlılık
Dördüncü tez: Hiçbir geliştirici, farklı tarayıcılarda girişler, düzeltmeler, kopyala-yapıştır veya geri dönüşlerde ortaya çıkabilecek her olası hata senaryosunu önceden öngöremez.
Risk
Yazılım "kilitlenir"; yalnızca sert bir yeniden başlatma çalışmaya devam etmeyi mümkün kılar.
Strateji
Hata durumunda işlemden önceki durumu geri yükleyen istisna yönetimi (exception handling) için fonksiyon yapı taşları sağlayın.
Dikkat edilmesi gerekenler
Birden fazla teknik (idealde kod örnekleri olarak) sağlayın: hazırlık kontrolleri, kontrollü işleme, son işleme/sonuç kontrolleri. Bu, basit fonksiyonları şişirir ancak karmaşık yazılım sistemlerini stabilize eder ve hareket güvenliği sağlar. Her geliştirici bu yapı taşlarını güvenli şekilde kullanabilmelidir.
Sonuç & Öneriler
Bir yazılım evi veya kurum içi BT olarak başarı, müşterilerin her zaman ihtiyaca uygun şekilde hizmet almasıyla mümkün olur – yalnızca 1-2 kişinin anladığı, bireysel olarak "bir araya getirilmiş" yazılımla değil.
Müşteri taleplerini fonksiyon kütüphanesi/alan modelleri ("dijital ikiz") içinde temsil eden, uyarlanabilirliğe göre tasarlanmış yazılım yapı taşları gereklidir. Boşluklar varsa, bir genişletme tüm müşterilere fayda sağlayacak şekilde tasarlanmalıdır.
Ayrıca ekiplerin sıkı bir şekilde yönetilmesi gereklidir: tekdüze uygulama yönergeleri (kullanım felsefesi, kütüphaneler, iç programlama kuralları) ve müşteri proje yönetiminden Product Owner'a, Teknik Lider'e kadar net rol sorumlulukları.
