UZAKTAN ÇALIŞAN YAZILIM EKİPLERİNİ YÖNETMEK
Yazılım ekipleri, işlerinin doğası gereği diğer projelerden farklı sorunlarla uğraşabilirler. Her özel proje türünün kendine has problemleri ve özelleşmiş çözümleri, yöntem ve araçları vardır. Farklı yöntemler ve bazı noktalarda özel ilgi gerektiren bir alan da, elemanlarının birbirinden fiziksel olarak uzak olarak çalışmak zorunda olduğu yazılım ekipleridir. İnternetin iletişimi ve uzaktan çalışmayı çok daha kolaylaştırdığı, farklı yeteneklerdeki insanlarla çalışmak için sınırlara bağlı kalınmayan günümüz dünyasında fiziksel olarak aynı ortamda bulunmayan takımların sorunlarını tanımlamak ve çözüm aramak, gerekli bir çabadır.
Öncelikle bu tür projelerde görevlerin şekillendirilmesi ve görev dağıtımının doğasına değineceğiz. Ardından yazılım projelerinin iki çok önemli unsuru olan proje yönetim araçlarına ve sürüm denetim sistemlerine değinecek, yazılı iletişim üzerine birkaç tavsiye sıralayacağız. Genel olarak yazılım projelerini hedef alsak da, aslında bu sorunlar aynı ortamsal dezavantaja sahip tüm ekipler tarafından paylaşılan sorunlardır, bu yüzden söz konusu tavsiyelerin, yazılım uzmanlarından daha geniş bir kitleye hitap ettiği düşüncesindeyiz. Özellikle yazılımla ilgili olan konularda da, herhangi bir geliştirme yöntemine (klasik, çevik ya da sarmal) değil, daha temel prensiplere bağlı olarak yorum yapmaya çalıştık.
Görevlerin belirlenmesi ve paylaşılması
Hedeflere ulaşmak için gereken görevlerin belirlenmesi ve sıraya dizilmesi, doğal olarak proje yöneticisinin sorumluluğudur. Ancak çalışanların birbirine uzak olduğu ekiplerde, görev dağılımının ve içeriklerinin şeffaf olarak paylaşılmasının önemi büyüktür. Aynı ortamda olan elemanlar bu görev dağılımına fiziksel olarak şahit olacakken, birbirinden uzak olanlar işlerin genel çapta açıkça ilan edilmesine ihtiyaç duyarlar.
Konuya işlerin sağlığı açısından baktığımızda, grubun her elemanının diğer elemanların ne üzerinde çalıştığıyla ilgili en azından kabaca bir fikrinin olması, birbirinden kopuk iş yürütülmesini önlemeye yardımcı olacaktır.
Örneğin eğer iki farklı işin yapılması, ikisinde de ortak bulunan bir bileşenin öncelikle tamamlanmasını gerektiriyorsa, tehlikeli olan iki elemanın da bu ortak bileşenin farklı birer tatbikini (implementation) yapmasıdır. Böyle durumlar proje çapında tutarsızlığın ve dengesizliğin yerleşmesine sebep olur. Her yazılım projesinin sorunu olan bu birden fazla tatbik durumu, yazılım kalitesinin düşmesine birkaç yönden birden sebep olur: Tatbiklerden birinde tespit edilip giderilen hata, diğerinde fark edilmeden kalabilir. Ya da tatbiklerden birinin davranışında kullanıcıya yansıyan ince bir fark, yazılımın insanla etkileşiminde tutarsız bir imaja kavuşmasına sebep olabilir.
Bir diğer basit ama önemli örnek, sürüm denetim sisteminde (version control system) meydana gelebilecek çakışmalar (conflict) olabilir. Sürüm denetim sistemleri her ne kadar çakışmaların önüne geçmek için donatılmış olsalar da, ikili dosyalar ya da karmaşık yapılı dosyalarda birden fazla kişi aynı anda yükleme yaptığında çakışmanın önüne geçemezler ve pes ederler. Halbuki projenin elemanları birbirinin yaptığı işten haberdar olursa, tam da kritik noktada insan faktörü devreye girip işlerini sürüm denetim sisteminin yorumlayabileceği parçalarda yüklenmesini sağlayabilirler.
İşlerin şeffaf olarak paylaşılması, elemanlar arası iş-sosyal ilişkilerin sağlıklı olarak yürümesinde de faydalı olur. Bir diğerinin de ürüne en az kendisi kadar katkıda bulunduğunu gören eleman, takım arkadaşlarına daha saygılı olur. Görevlerin ilanı sırasında belki önceden arka plana itilmiş olan takım bilinci, bu ilan sayesinde öne çıkar, tekrar uyanır.
Projenin beyni: Çevrimiçi yazılım proje yönetim araçları
Bir yazılım projesinin yürütülmesinin içerdiği günlük işler bile, hatırı sayılır derecede bir iş gücü gerektirir. Görevlerin planlanması ve atanması, süre tahminleri ve bu tahminlerin takibi, bitirilen işlerin olağan bir prosedüre bağlı olarak onaylanması, hataların kayıt altına alınması ve takip edilmesi, sürümlerin ve içerecekleri özelliklerin planlanması gibi işlerin her biri, hem entelektüel çaba gerektirdikleri gibi, hem de ciddi anlamda hesaplama, yazı ve verilerin yönetilmesi gibi mekanik yükler getirirler. Ekibin elemanlarının tek bir ofisten çalışmıyor olmasıysa iletişim yükünü kayda değer derecede artırır.
Bahsettiğimiz çeşitli sorunlara hitap eden irili ufaklı bir çok yazılım mevcut, ancak güncel anlayışta en popüler çözüm internet üzerinde çalışan proje yazılım çözümleridir. Ekibin tüm üyelerinin üye olacağı böyle bir sistem, başta iletişim ve dağıtım olmak üzere yazılı yükün çoğunu üzerinizden alacaktır. İnternet üzerinde olmasının getirdiği sürekli olarak ulaşılabilirlik avantajıyla birlikte eğer çalışma dinamiklerinizi bu sistem üzerinde yürüyecek şekilde oturtabilirseniz, bu sistemlerin “kanıt-temelli süre tahmini” ya da “sürüm tarih planlama” gibi bir çok nimetinden de faydalanabilirsiniz. Dahası bu sistemi sürüm kontrol sisteminizle entegre edebilir, otomatik-derleme hizmetini de devreye sokarak geliştirme sürecinizin risk hanesindeki rakamı bir adım daha düşürebilirsiniz.
Projenin yürütülmesi için kullanılan bir çevrimiçi araç, bitirilen işlerin tespiti ve onaylanmasını da sağlam bir sürece bağlayacaktır. “Tamam” olarak işaretlenen bir işin gerçekten tamam olup olmadığının denetlenmesi için gereken kişinin onayına otomatik olarak sunulması bile gayet kullanışlı bir lüks olarak değerlendirilebilir.
Bu çevrimiçi yazılımların en iyi örneklerinden biri Assembla, biri FogBugz, bir diğeri de Jira olabilir. Bugzilla, Trac, Wiki gibi özelleşmiş araçları bir başlık altında toplayarak hizmete sokan bu ürünler, yazılım proje yönetimini özel olarak hedef alırlar. Her üçünün de klasik metotların yanında çevik geliştirme yöntemleri için eklentileri, altyapısal destekleri bulunmaktadır.
Olmazsa olmaz: sürüm denetim sistemi
Sürüm denetim sistemleri (version control system) ciddi bir yazılım geliştirme sürecinin olmazsa olmaz parçasıdır. Tüm kod ve verinizi taşıyıp zaman içindeki değişimlerini kontrol etmenizi, istediğiniz bir sürüme geri dönmenizi sağlayabildikleri gibi aynı zamanda bir çok kişinin aynı dosya üzerinde çalışmasını da sağlayabilirler. Üstelik elemanlarının birbirinden fiziksel olarak bağımsız çalıştığı projeleri düşündüğümüzde, sürüm denetim sistemlerinin baş belası çakışma anlarının bile aslında büyük bir nimet olduğunu anlarız, çünkü bize uyum sorunlarını göreceli olarak erken tespit etme şansı verirler.
Proje yönetim yazılımınızla entegre edilmiş bir sürüm denetim sistemi, kendisiyle ilgili haberleşme yükünü de üzerinizden alacaktır. Değişiklik anında diğer üyelere haber vererek iş kaybını ve çakışmayı önlemeye yardımcı olur. Burada dikkat edilmesi gereken nokta, bir değişiklik anında ekranınızdaki açıklama hanesine net ve açıklayıcı bir bilgi girmektir. Bu açıklama mesajına “Sorgu ekranı değişiklik” kötü bir örnekken, iyi bir örnek şöyle olabilir:
“#334 numaralı görev üzerine araç sorgu ekranındaki Tarih hanesinin İngiliz tipi tarih formatından Türk tipi tarih formatına geçişi sağlandı”.
Böyle bir açıklama mesajı, değişikliği izleyenler için çok daha faydalı olacaktır.
İnternet üzerinden çalışan ekiplerde birbirine geçici dosya gönderme gereği sıklıkla doğar. Sık yapılan bir hata da, sürüm denetim sistemini bu amaç için kullanmaktır. Daha sonra bu geçici dosyayı depodan silseniz bile, sürüm denetim sistemi bu dosyayı tarihsel bir bilgi olarak sürekli olarak tutmaya devam edecektir. Yedeklerinizin boyutu o miktarda artacak, herhangi bir versiyona dönmek istediğinizde o dosya da projenizin bir parçası olarak karşınıza çıkacaktır. Sürüm kontrol sisteminin maliyetle
ri de bununla doğru orantılı olarak yükselecektir. Bunun olmasını önlemek için, projenize özel, sürüm kontrol sistemi dışında ayrı bir depolama alanı edinmeniz isabetli olur.
Sürüm denetim sistemlerinde ekiplerin ayrıldığı bir nokta, dizinlerin düzenlenme stratejisidir. En basit yöntem (1) tek bir ana dizin (“trunk”) kullanıp tüm kullanıcıların aynı dizin üzerinde çalışmasıdır ama projenin eleman sayısına ve dosyalara erişme sıralarına göre çok sorunlu bir hal alabilir. Diğer bir yöntem (2), ana dizini o an üzerinde çalışılan görevlere göre dallandırmaktır. Örneğin projenin son halini taşıyan bir temel kopya (“trunk”), yanında da görevler için ayrı birer kopya (“görev-araçSorguEkranı”, “görev-veriDüzenleme”) görev tamamlandıktan sonra “trunk”a birleştirilmek üzere bulundurulabilir. Bu durumda çakışma sorunları tüm ekip genelinde meydana gelmektense, o görev üzerinde çalışan kişiler arasında oluşur ve daha kolayca çözülür. Dizin stratejisinde bir diğer (3) yaklaşım da, “trunk”ın yanında kişilere özel birer kopya (“development-görkem”, “development-özgür”) bulundurulmasıdır. Elemanlar o kopya üzerinde çalışmalarını bitirdikten sonra değişiklikleri “trunk”la birleştirirler.
Hangi dizin yapısını kullanmanın doğru olacağı, projenin doğasına ve kullandığınız yazılım geliştirme süreç tipine göre değişebilir, ancak birbirinden uzak ekip elemanlarının iletişim bağlarının kopuk olduğu göz önüne alındığında, kişilere özel birer kopyanın bulunduğu sistemin daha uygun olacağı söylenebilir.
İletişim dili ve formatı
Birbirinden uzak çalışan bir ekipte, iletişimin çoğu mecburen yazılı olarak sürdürülmek durumundadır. Buna yalnızca gün içinde gönderdiğiniz e-postalar veya anlık mesajlaşmalarınız dâhil değil, aynı zamanda üzerinde çalıştığınız dosyalara verdiğiniz isimler, kullandığınız kısaltmalar, hazırladığınız belgeler, kullandığınız çevrimiçi araçlardaki açıklama haneleri de dâhildir.
Başta elektronik postalar olmak üzere, internet üzerinden sürdürülen etkileşimlerde en sık yapılan hatalardan biri, alıcının mesajı okurken bulunacağı bağlamı düşünmemektir. Bir e-postaya cevap verirken, e-posta programınızın size gelen mesajı sayfada bırakıp sizin onun üzerine yazmanızı istemesi bu yüzdendir ve bu basit kuralın hiçe sayılıp sadece yeni mesajın içirildiği bir mesaj gösterilmesi, e-posta ahlakına aşina insanlar tarafından hoş karşılanmaz. Bağlam denilince, bu sadece bir önceki e-posta değil, yeni girilen bir konu da olabilir. Örneğin her elektronik posta, öz ifadesini açık etmeden önce, durumu açıklayan bir giriş bölümü bulundurmalıdır. Açıklamak için, bir kötü bir de iyi örnek vermek yine yerinde olacaktır. Kötü örnek, bağlamı açıklamadan direk konuya girer:
“şifrenin açık görünmesine karar verdik, o şekilde yapacağız.”
Konudan haberdar olmayan biri, şifrenin hangi şifre olduğunu ve şifrenin açık görünmesinin ne anlama geldiğini anlamakta zorlanabilir. Alıcı konudan haberdar olsa bile, okuduğu anda bağlantıyı kurması zor olacaktır. İşi şansa bırakmaktansa, eğer gönderen önce bağlamı anlatıp ondan sonra mesaja geçse çok daha kaliteli bir iletişim ortaya çıkarır:
“Kullanıcı girişi bölümünde girilmesi gereken şifrenin, yazılma sırasında gizli mi yoksa görünür mü olmasının daha doğru olacağını tartıştığımız bir toplantı gerçekleştirdik. Kullanıcılarımızın birçoğunun klavye kullanma hızının yüksek olduğu ve yazılımı kullandıkları ortamda genellikle yalnız oldukları sebeplerini göz önüne alarak, yazım sırasında şifrenin 5sn süreyle görünür olmasının bir dezavantaj getirmeyeceği gibi, kullanım açısından pratik bir avantaj sağlayacağına karar verdik.”
Bu örnek hem giriş sırasında konuyu hatırlatmakta, hem de konuya daha açık bir sebeple yaklaşarak alıcının kavrayışını güçlendirmektedir. Kelime sayısı bakımından kötü olarak verdiğimiz örnekle iyi olarak verdiğimiz örnek arasında çok fark olabilir. Fakat bir kere yazılan bu ileti en az ekipteki eleman sayısı kadar, belki bu sayının iki katı kadar kez okunacağı için, metnin akıcılığı ve anlaşılabilirliğine harcanan vakit asla kaybedilmiş sayılmaz.
Son Yorumlananlar