Ship It:Bölüm 3

Pratik Proje Teknikleri

Bu bölümün ilk girişinde neden bazı projelerin kaliteli,başarılı olupda erken bittiğini ama bazı projelerin kalitesiz başarısız ya da geç kaldığını sorarak başlıyor.Bunu sebebini iletişim ve işbirliği olduğunundan bahsediyor.Benimde düşündüğüm şeyleri burada da tekrarlamış kitap. Tutkulu hevesli, işbirliği halinde iyi iletişim kuran bir takım projenin başarısı için en önemli faktörlerdendir. Takım olabilmek içinde tabiki en önemli faktörlerden biri iyi iletişim ve işbirliği içinde olmak . Bu noktada kitapta aşağıdaki gibi vurucu bir söz yazılmış.

Though good collaboration doesn’t guarantee a project’s success, poor collaboration almost always guarantees a project’s failure.

Evet söz çok hoşuma gitti.İyi işbirliği,iletişim projenin başarılı olacağını garanti etmez fakat kötü iletişişim,işbirliği her zaman projenin başarız olacağını garanti eder.Bu bölümde aşağıdaki gibi takım olarak işbirliğini arttıracak teknikler üzerinde duruluyor.

Yapılacaklar Listesinden Çalışın

Bu bölümde aslında uzunca yapılacaklar listesinden(to-do list) bahsediliyor.Yapılacaklar listesini proje olarak kişisel olarak tutmanın genel gidişatı yolunda tutmak için önemli olduğunu söylüyor. Kendim kişisel olarakda sürekli yapılacaklar listesi tutuyorum. Hatta şuanda çok sevdiğim rememberthemilk sitesini tavsiye edebilirim. Web üzerinde oldukça pratik yapılacaklar listeleri oluşturup,bunlara öncelik atayıp yayınlayabiliyorsunuz. Tabi bunu illa bir yazılım yoluyla yapmak zorunda değilsiniz. En güzel kayıt aracı hala bence defter kalem ikilisi. Mesela daha önceki çalıştığım firmada bunu proje içinde uygulardık. Öncelikle müşterinin isteklerine göre haftalık yapılacaklar listesi oluşturup herkes için bunu yayımlanırdı. Ardından proje yöneticimiz ile birlikte bunlara öncelik atardık ve önceliği en yüksek olan özellikleri geliştirmeye başlardık. Önceliği yüksek olan öğeler bitmeden düşük öncelikli öğelere geçmezdik. Bu şekilde önüimüzdeki işleri rahatça takip edebilirdik.Ayrıca müşteride şuanda hangi özellikler var, ve projenin genel gidişatını kolaylıkla öğrenebiliyordu. Liste dediğimiz şey çok abartlama gerek yok kısaca aşağıdaki gibi diyebiliriz.

    Visual Earth entegrasyonu yapılacak(Öncelik 1) Zoom out seçeneği eklenecek(Öncelik 2) NAnt bile build scripti yazılacak(Öncelik 3) Geliştirme makinası Ubuntu üzerine taşınacak(Öncelik 3)

Gördüğünüz gibi liste kısaca yukarıdaki gibi yapıya sahip.Kitapta listelerin sahip olması gereken temel özelliklerini sıralayarak açıklamış. Liste aşağıdaki özelliklere sahip olmalıdır.

    Herkes tarafından ulaşılabilir(Listeyi gizledikten sonra bir faydası yok) Önceliklendirilmiş(Yukarıda bahsettik) Zaman tahmini yapılmış(Projede tahmin sürelerinin geliştirilmesi için yapılaraklara zaman tahmini eklenmesi ) Canlı(Bir defa yaz kenara at değil, sürekli gelişen değişen) Ölçeklenebilir(“Performansı arttır” gibi bir öğe yerine “login ekranında giriş 5 saniyeden kısa olmalıdır”.) Hedef kitlesi belirli(Takımın yapılacaklar listesi ya da kişisel yapılacaklar listesi)

Teknik Lider

Bu kısımda projede bulunması gereken takım lideri,teknik lider gibi kişilerin rollerinden ve neler yapması gerektiğinden bahsediyor.Öncelikle teknik bilgisi yetersiz bir proje yöneticisiyle çalıştınız mı bilmiyorum fakat ben acı şekilde bunu tecrübe ettim. Böyle biriyle çalışmanın en büyük problemlerinden biri sizin geliştirdiğiniz yazılımın sorunlarından , teknik detayından çok fazla haberdar olmadığı için çoğu zaman gerçekçi olmayan planlar çıkarabiliyorlar. Onun için yeni bir özellik desteği eklemek 1 günü alabiliyor fakat işin içinde In Hohe und Art kann sich ein spielautomaten online Bonus allerdings von Casino zu Casino erheblich unterscheiden. olan siz oradaki problemi biliyorsunuz ve bunun bu sürede çıkarılamayacağını söyleyince muhtemelen şöyle bir cevap alıyorsunuz; “A tablosuna yeni bir alan ekleyelim bu problemi çözecektir” :) Bu arada konu ile alakalı değil fakat söylemeden geçemiycem, DB oriented insanlarla ya da proje yöneticisiyle çalışmanın en ilginç bulduğum yanlarından biride her problemin çözümünü bir tablo ile ya da tabloya bir alan eklemeyle çözmeleridir :). Tabi proje yöneticiniz yazılım hakkında çok iyi olan biriside olabilir. Fakat bu da problemi çözmeyecektir. Çünkü takım içinde olmadığı için sizin kod içindeki problemlerinizi bilmediği için aynı problemler devam edecektir. Bu yüzden kitaba kesinlikle katılıyorum.Proje içerisinde Takım Lideri ya da Teknik Lider bulunması gerekiyor. Böylelikle takımın problemlerini bilip onlara daha uygun çözümler ve daha uygun planlar çıkarabilir. Teknik Lider neler yapar kitapta şu şekilde belirtmiş.

    Müşterinin belirttiği önceliklerle takımın çalışmasının örtüşmesini sağlar Takımın çalışmasının üst yönetime ya da proje yöneticisine düzgün olarak sunar. Teknik konuları teknik olmayan insanlara iletir. Projede Teknik olmayan konuları takıma bildirir. Takım üyelerine yön çizer Projenin özellik listesini düzenler. Yapılacak özellikleri takım ile birlikte önceliklendirir Takımın dış etkenlerden rahatsız olmamasını sağlar

Hergün İşbirliği ve İletişim İçinde Olun

Bu kısımda takım olmanın en önemli unsurlarından olan iletişimden bahsetmiş. İletişimi arttırmak için özellikle günlük toplantıları anlatmış. Öncelikle neden iletişimi arttırmalıyız ona değilenim. Aynı problemleri tekrar çözmemek için,tekerleği tekrar icat etmemek için iletişim gerçekten önemli.İletişim; Takımda herkesin birbirinin yaptığı iş hakkında fikir sahibi olması, o işin başka kişiler tarafından yapıldıysa bilgilerinin paylaşılması, karşılaşılan hataların paylaşılması ve bu hatalar ile daha önceden karşılaşanların bilgilerini paylaşarak probleme daha hızlı çözüm üretmesini sağlar. Özellikle daha az bilgili takım elemanlarının bu konularda daha fazla bilgi ve tecrübeye sahip geliştiricilerden faydalanarak problemlere nasıl çözüm bulacağını anlaması ve takım olarak gelişmeyi arttırır. Ayrıca hergün takımın durumunu görerek projenin yolundan çıkmamasında önemli rol oynar.

Burda iletişimi sağlamak için kitap Scrum,XP gibi yöntemlerde kullanılan günlük toplantı yöntemini tavsiye ediyor. Ayakta toplantıların bir toplantı havasından çıkıp günlük bir aktivite olması için herzaman aynı yerde aynı saatte yapılmasını tavsiye ediyor. Burada toplantı deyince benim aklıma bitmek bilmeyen haftalık ya da aylık şirket toplantıları geliyor. Daha önceden bu tarz toplantılarda çok bulunmuştum açıkçası herkesin benim gibi bitsede kurtulsak modunda olduğunu görebiliyordum. Çünkü toplantı belli bir süre sonra gereksiz uzayıp çıkmaza giriyordu.Bazen kişiler arasındaki tartışmalara dönüşüyordu.Bu yüzden günlük ayakta toplantılar bu bakımdan oldukça verimli.Toplantının süresi 15 dakikayı geçemiyor. Herkes dün neler yapmış bugün neler yapacak onları anlatıyor. Ayrıca karşılaştığı problemler varsa onlardan bahsediyor. Bu şekilde problem ile daha önce karşılaşmış ya da çözümünü bilen biri toplantıdan sonra takım arkadaşına yardım ederek problemi daha hızlı çözmesini sağlıyor.Toplantıda tabi yaptığı işi anlatırken geliştirici işimin yarısını bitirdim diye yuvarlak cümlelerle değil dün login ekranını yaptım bugün şunları yapacağım diye daha açıklayıcı cümleler ile belirtiyor.

Kodunuzu Gözden Geçirin

Klasik adıyla Code Review. Sizinde başınıza mutlaka gelmiştir. Bir takımın içinde, diğer takım öğeleri tarafından yazılan kodun size tamamen yabancı hiçbirşey ifade etmediği durumlarla karşılaşmıştırsınız. Tabi bende karşılaştım. Başkasının yazdığı koda dokunmadığınız sürece problem yok fakat diğer takım arkadaşınızın başka bir projeye geçmesi, tatile çıkması, işten ayrılması vb.. gibi durumlarda kaçınılmaz son olarak kodu değiştirmek zorunda kaldığınızda asıl problem o zaman başlıyor demektir. Daha önce hiç görmediğiniz kod ile karşı karşılayısınız ne yapacaksınız kodun ne testi var, ne düzgün bir yapısı,okunaklı değil vs..İşte bu tarz problemlerle takım olarak çok fazla karşılaşmamak için kitap ve ben klasik adıyla Code Review yapmanızı şiddetle öneriyoruz :)

Yazılım geliştiren bir takımın bence iletişimi ve bilgiyi arttırma konusunda en efektif yöntemlerden biri. Ayrıca hataların bulunması ve problemlere daha çabuk çözüm bulunması için oldukça faydalı. Aslında çok basit bir işlem olmasına rağmen çoğu geliştirici ekibinde neden hala uygulanmıyor bir türlü anlamış değilim. Mantık çok basit geliştirdiğiniz bir özelliğin kodunu versiyon kontrol sistemine check in etmeden önce kodunuzu gözden geçirecek bir ya da birkaç takım üyesi bulun. Kodunuza bakıp fikirlerini söylesinler iyileştirme ya da hatalı bir özellik varsa bildirsinler ve ardından kodunuzu versiyon kontrol sistemine gönderin. Bu kadar basit. Ayrıca kodunuzu başka bir takım arkadaşınızla gözden geçirdiğinizde çözemediğiniz bir problem varsa ona anlatırken farklı bir perspektifle baktığınız için kafanızda büyük ihtimalle çözümü bulacaksınız.Buna Rubber Ducking deniyor.

Ayrıca tecrübeli elemanların acemi elemanlara kodları gözden geçirirken bilgi aktarması çok kolay.Özellikle Object Oriented,Design Patterns,Refactoring konularında bilgili deneyimli geliştiriciler kod gözden geçirmeleri sırasında bu bilgilerini takım üyelerine problemlemler üzerinde anlatıp takımın gelişmesine de katlı sağlarlar.Ayrıca gözden geçirme sırasında kodunuz karşıdaki tarafından anlaşılamıyorsa bu kodunuzu basitleştirmeniz gerektiğinin işaretidir.

Kod Değiştiği Zaman Uyarı Gönder

Bu kısımda versiyon kontrol sistemi gibi kodun herhangi bir yeri değiştiğinde gerekli kişilere uyarı mesajları halinde bunun bildirilmesini tavsiye ediyor.Özellikle kimin ne yaptığını izlemek için efektir bir yöntem olduğunu söylüyor.Bu konuda hiç tecrübem olmadığı için yorum yapamıyorum

Özet Liste

Yapılacaklar Listesi:

Herkes tarafından izlenebilir
Önceliklendirilmiş
Zaman tahmini yapılmış
Sürekli değişen

Teknik Lider:

Projenin özellik listesini yönetir
Developerların yaptığı işleri ve güncel durumlarını kontrol eder
Yapılacak özelliklere öncelik atamada yardımcı olur
Takımı dış etkilerden izole eder.

Günlük Toplantılar

Kısa tutulmalılar
Konular belirgin olmalı
Problemleri anlatın toplantıda çözmeye çalışmayın

Kod Gözden Geçirmeleri:

Küçük miktarda sık sık kodu gözden geçirin
Gözden geçiren sayısı bir ya da iki kişi olsun
Gözden geçirme yapılmadan kodu yayınlamayın

Code change notifications:

EMail ile değişiklikleri bildirin
Değiştirenin adını bildirin
Değişikliğin amacını yazın