Agile disiplinini benimseyen Dr. Mark J. Balbes yazılımcılara kendi deneyimlerinden gelen öğütler veriyor.
İnsanlara söylemeyi sevdiğim cümlelerden birisi şudur: “kendimi her zaman işin dışında tutmaya çalışırım”. Diğer bir deyişle, ne iş olursa olsun, kişisel olarak bir proje üzerinde çalışmam gerektiğinde, ya ekibin işi sahiplenebilmesi için bir düzenek oluşturabilmek ya da o projenin kimseye ihtiyacı olmamasını sağlamak için yollar araştırırım. Kişisel tecrübelerime göre bunu ne kadar çok yaparsam meslek yaşamımda o kadar çeşitlilik yaratabiliyor ve daha mutlu oluyorum. Aynı şeyleri tekrar tekrar yapmaktan hoşlanmıyorum, en azından aynı şekilde.
Meslek yaşamımda bu görüşün tam tersini benimseyen birçok insanla tanıştım. Bir işe ya da işler bütününe takılıyor ve o işi sahiplenmeyi kabul ediyorlar. Bana göre bunun iki sebebi var. Ya bu insanlar benzer işleri yapmanın sağlamlığında rahat ediyor ve eğleniyorlar ya da işlerini güvenceye almak için şirket içinde vazgeçilmez olmak istiyorlar. Birincisi için iş yerinizde mutluluğu yakaladığınız için memnun olurum. İkincisi için ise acilen yordamınızı gözden geçirmenizi öneriyorum.
Kişisel deneyimlerimden şunu öğrendim ki ne kadar fazla farklı konu öğrenirsem, her çeşit sorunla çıkabilen birisi olarak işverenim için daha değerli olurum. Elbette belirli konularda uzmanlaşmayı ben de istiyorum fakat karşılaşacağım her tür sorunu çözebileceğim konusunda kendime güvenim varsa olukça hızlı bir şekilde (neredeyse) uzman seviyesine çıkarım. Bunu kibirlilik olarak almayın, sadece çok fazla deneyimin sonucu.
Olay aslında şu: Geliştirme sürecinizi bu şekilde inşa ederseniz, sizin için değişim doğal, beklenen ve sıradan bir olay olur. Bundan sonra projenizde bir değişiklik olduğunda, bu sorunla günlük işlerinizi aksatmadan başa çıkabilme yetisine kavuşursunuz. Elbette bu durum proje takviminizi ve birçok diğer etkeni olumsuz etkileyebilir. Fakat günlük her gün değişikliklerle başa çıkma konusunda uygulama yaparsanız sonuçta ekibiniz daha iyi olur ve bir gün gerçek bir değişiklikle karşılaştığınızda bunu günlük bir işmişçesine halledebilirsiniz.
Aynısı işe yaramaz olmayı öğrenmekte de geçerli. Eğer her gün kendinize “neden bu işi yapıyorum?” diye sormayı alışkanlık haline getirirseniz, git gide tekrar eden işlerle başa çıkmakta daha iyi olur ve onları kendinizden uzak tutarsınız.
Basit bir örnekle açıklayayım. Diyelim ki projenizin geliştirme yöneticisi sizsiniz. İşiniz uyumu sağlamak, kodları geliştirici-kalite kontrol-üretim bölümleri arasında taşımak, hepsi tarafından uygun görülecek bir sistem geliştirmektir. Çoğu zaman, bilgisayar başına geçip vaktinizi bozuk komutları belirlemek, birleştirme çakışmalarını çözmek, kodu derlemek için IDE’nizi açmak ve test yapmakla geçirirsiniz.
Peki, nasıl işe yaramaz olacaksınız?
İşin kolay kısmı teknik yaklaşımınızı değiştirmektir. Piyasada hangi teknolojiyi kullanıyor olursanız olun ona uyumlu birçok otomatik geliştirme aracı var (Jenkins, Cruise Control, Team System gibi). Bunlar genellikle kaynak kod deponuzu izleyen, bir değişiklik olup olmadığını kontrol eden, kendiliğinden yapılan testleri de içerecek şekilde yazılımı derleyebilen ve başarı ya da başarısızlık durumunda haber verebilen bir kesintisiz bütünleştirme sisteminin parçasıdırlar. İşte! Oldu bitti! Sunucuyu yapılandırmak için bir defa zaman harcadınız ve bir daha asla yazılımınızı el ile derlemek zorunda kalmayacaksınız.
İşin zor kısmı ise bölümleri idare etme süreçlerini düzeltebilmek. Sunucuları yapılandırmak birden bire bölümler arası uyumu sağlamaz ve çatışmaları onarmaz. Yani eğer kendinizi işe yaramaz hale getirmek istiyorsanız süreçleri de değiştirmek zorundasınız. Bu sadece sizin değil diğerlerinin de çalışma şeklini değiştirmeniz gerektiği anlamına geliyor. Süreci değiştirmek gayet basittir. Geliştirme bölümü için, yazılım içindeki kısımların oluşturulmasından sorumlu geliştiricileri, ilgili kısımlarla işleri bittiğinde onları birleştirme sorumluluğunu verin. Kalite kontrol ve üretim bölümleri için ise ekibinizi işin sorumluluğunu almaya ikna etmeniz ve iş bölümü için bir yöntem bulmanız gerekir. Bir Kanban işleyişini göz önüne alarak, yazılımın bu iki bölüm arasındaki dolaşımını basitçe düzenleyebilirsiniz.
Şimdi bazılarınız aklından şunu geçirmeye başladı: “Yazarın bize tek söylediği işlerimizi başkalarının üstüne yıkmak!”. Bu doğru bir değerlendirme olmasa da doğru yönü işaret etmesi açısından önemli. Kendinizi işe yaramaz hale getirmek işlerinizi başkasının üstüne yıkma meselesi değildir. Olay tüm ekibin sorumluğu üstlendiği ve işleri basitleştirip hızlıca bitirdiği tekrarlanabilir bir iş süreci oluşturabilmekte. Böylece işi kimin yaptığı önemsizleşir. Bazen işi siz yapıyor olursunuz ama artık diğer şeyler için daha çok vaktiniz kalır. Ayrıca, ekibin yeni süreci kabul etmesiyle artık bir hatayı tek başınıza karşılamak durumunda kalmazsınız.
İşte size bir alıştırma. Gün boyu yaptığınız her şeyi yazın. Sonra her birine tek tek göz atıp kendinize sorun:
Hatanın tek sorumlusu ben miyim?
İş sürecimizi bu sorumluluğu tüm ekiple paylaşacak şekilde nasıl değiştirebilirim?
Bunu yapma gereksinimimi nasıl ortadan kaldırabilirim?
Ekip bu işi kendiliğinden yapabilir duruma nasıl gelebilir?
Kıssadan Hisse
Bu makale sadece yazılım ile ilgili değildi. Ne iş yapıyor ya da he tür bir sürecin içinde olursanız olun, iş hayatınızı daha yüksek, daha iyi ve/veya daha değişik bir noktaya taşımak istiyorsanız o zaman kendinizi işinizde görünmez kılın.
Kaynak: http://www.adtmag.com