Çevik Organizasyonlarda Bilgi Paylaşımı Kültürü Oluşturmak Üzerine

Motivasyon
Yazılım geliştirme neredeyse tamamı insan faktörüne bağlı ve bilgiye dayalı bir iştir. Yazılımcılar karşılarına çıkan karmaşık problemler için verimli ve yaratıcı çözümler üreterek arzulanan özellikleri geliştirmek için çabalarlar. Geliştirme süresinde çalışanların bilgi, beceri ve deneyimlerinden faydalanır. Bilgi ve deneyim zaman içerisinde kazanılır. Bir yazılımcının bilgi ve deneyiminin artması, becerilerinin geliştirmesinde önemli etmenlerden biridir. Becerikli çalışanlara sahip, bilgi ve deneyim seviyesi yüksek takımlar, çoğunlukla daha kaliteli, daha esnek, daha dayanıklı ve değişimlere ayak uydurabilen yazılımlar üretirler. Bilgi ve deneyimden yoksun takımlarda ise hiç bitmeyen sorunlar nedeniyle başarısızlık kaçınılmaz olur.

Yazılım projelerinin başarısızlığı altında türlü nedenler olabilir. McConnell’e göre yapılması muhtemel 36 farklı klasik hata vardır. Bu hatalar genel olarak insan, ürün, süreç ve teknoloji odaklıdır ve yazılımdan bağımsız sıklıkla yaşanır. Bu naddeler ışığında, yıllar süresince üzerinde çalıştığımız ve halen geliştirmekte olduğumuz yazılım projelerine baktığımızda, karşılaştığımız sorunların başında çalışan motivasyonunun düşüklüğü, ürün ve teknoloji bilgisinin zamanla azalması, yazılım geliştirme süreçlerinde yaşanan aksaklıklar ve bunlara bağlı yaşanan sorunlar gelmektedir. Tüm bu sorunların kaynak nedenlerini araştırdığımızda, karşımıza hepsi için ortak bir madde göze çarpıyor: Başarısız bilgi yönetimi.

Yazılım Geliştirmede Bilgi Türleri
Yazılım geliştirmede bilgi birkaç türden oluşur.

Teknoloji bilgisi yazılımcının yazılım teknolojileri hakkında edindiği bilgisidir. Okuyarak edinilebilecek bu bilgi, bilfiil projelerde uygulandığında deneyime dönüşür ve yazılımcının konuya tam hakimiyet kurmasını sağlar. Teknoloji bilgisi adı altında programlama dilleri, ilgili uygulama iskeletleri, kütüphaneler, donanım, sunucular, test ve sürüm gönderme teknolojileri listelenebilir.

Ürün ve alan bilgisi geliştirilen yazılım, yani ürünün kendisi ile alakalı bilgilerdir. Yazılımın kaynak kodu, nasıl çalıştığı, nasıl kurulduğu, sistemin genel ve detaylı tasarımı, iş akışları ve süreçleri bu tip bilgi içerisinde yer alır. Ayrıca bu tür içerisinde projenin ilgili olduğu alan bilgisini de sayabiliriz. Örneğin, bir bankacılık uygulaması yapılıyorsa bankacılık bilgisi ya da bir ödeme sistemi yazılıyorsa ödeme sistemleri ile alakalı konular bu türden sayılabilir.

Süreç ve yöntem bilgisi yazılım geliştirme yöntemleri ve teknikleri ile alakalı bilgilerdir. Daha kaliteli ve daha az hatalı, esnek ve dayanıklı sistemler oluşturabilmek için gerekli olan mühendislik uygulamaları ve proje yönetimi süreçleri hakkında bilgiler bu bilgi türüne örnektir. Örnek vermek gerekirse, test güdümlü programlama, eşli programlama, sürekli birleştirme, kod gözden geçirme gibi mühendislik uygulamaları yanında tekrarlamalı geliştirme, sık sürüm çıkma, analiz ve yazılım fazları, test süreçleri gibi konular süreç ve yöntem bilgisi altında düşünülebilir.

Deneyimler ile edilinilen bilgi, kişinin geçmiş deneyimleri sırasında edindiği bilgilerdir. Deneyimlediği her teknoloji, uyguladığı her teknik, çözdüğü her sorun kişinin konu üzerinde hakimiyetini arttırır ve karşılaştığı yeni sorunlara daha verimli çözümler geliştirme için gerekli bir bakış açısı katar.

Bir yazılımcının tüm detayları ile başarılı bir yazılım geliştirebilmesi için öncelikle üzerinde çalışacağı teknolojileri ve alan hakkındaki konuları, uygulayacağı mühendislik tekniklerini, takımı tarafından benimsenmiş süreçleri ve kullanılan yöntemleri bilmesi gerekir.

Bilgi Yönetiminde ve Paylaşımında Yaşanan Sorunlar
Bilgi zamanla erir. Başka bir deyişle, ürün, alan, teknik ya da teknoloji bilgisinin zaman içinde giderek azalır, en sonunda kimseye aktarılamazsa tükenir. Bu nedenle yazılım geliştirmede en büyük mücadelelerden biri bilginin yönetiminde ve paylaşımında yaşanır. Yaşanan sorunlar bazı zamanlar sadece çalışan verimliliğini düşürürken, bazen de projelerin başarısız olmasına, hatta büyük maddi kayıplara neden olabilir.

Bilgi paylaşımında yaşanan problemlerin nedenleri şöyle özetlenebilir.

1. Yetersiz Geliştirme Süreçleri: Bilgi paylaşımının yazılım geliştirme süreçlerine dahil edilmemesi ya da aşırı detayda belgeleme zorunluluğunda olduğu gibi gerçekçi olmayan süreçlerle bilgi akışını yavaşlatma durumudur. Bilgi paylaşımı takım kültürünün temel taşlarından biridir ve burada yaşanan aksaklıklar neticesinde çalışanlar takımın başarısı yerine bireysel başarıya odaklanır ve bilgi paylaşımında isteksiz davranırlar. Gerek takım kurumunun inşası, gerek de iletişimi arttırabilmek adına bilgi paylaşım adımları süreçlere dahil edilmelidir.
2. Çalışanların Davranışsal Yönden Hazır Olmamaları:Her çalışan bilginin paylaşımı konularında aynı hassasiyeti göstermeyebilir. Davranışsal sorunlar nedeniyle yaşabilecek sorunlar, ancak ilgili kişilere uygulanacak özel ilgil ve eğitim ile aşılabilir. Davranışsal sorunlar şöyle belirtilebilir.
   1. Bilgi Paylaşmada Bencillik: Çoğunlukla takım çalışmasına uygun olmayan kişilerde görülen, bireysel başarıya saplantılı bir şekilde odaklanma durumudur. Bu tür kişiler bilgiyi paylaşmada ve yardımlaşmada isteksizdirler. Kendi bireysel başarılarını takımın başarısının üzerinde tutarlar. Takım içerisinde hızla yayılan bir “bencillik” havası oluşmasına neden olurlar. Takım üyeleri birbirinden kopuk bir şekilde çalışmaya başlarlar, bu da motivasyonu ve verimliliği ciddi oranda düşürür, üzerinde çalışılan yazılımda gecikmelere ve kritik problemlere neden olur.
   2. Bilgiyi Paylaşmada İsteksizlik: Geçmişimizden gelen korkularımız ve içimize sinmiş “ben bunu yapamam” düşüncesi, yani öğrenilmiş çaresizlik nedeniyle bilgi paylaşımına ve cesaret ve girişim gerektiren tüm etkinliklere olan genel isteksizliktir. Daha çok “insan önünde konuşma korkusu” ya da “yeterince bilmiyorum fobisi” şeklinde kendini gösterir. Kişi kendini hiçbir zaman bilgisini başkaları ile paylaşacak kadar bilgili bulmadığı için bildiklerini de paylaşmakta isteksiz davranır. Bu tür kişiler aşağılık kompleksi ya da asosyallik gibi farklı psikolojik sorunlarla içiçe bulunabilirler. Bu tür kişilerin bulunduğu takımlar bilgi paylaşımında ciddi sorunlar yaşayacakları için takım ruhunu canlı tutmakta zorlanırlar.
   3. Odaklanma Sorunları: Kişinin altından kalkamayacağı kadar çok konuyu öğrenmesi gerektiğini düşünüp hiç bir konuya tam anlamıyla konsantre olamama durumu. Bu durumu özellikle yazılım teknolojilerini ve tekniklerini öğrenmeye hevesli deneyimsiz yazılımcılar yaşarlar. Her konuyu araştırıp detaylıca öğrenmek, daha çok bilgi edinmek isterler. Ancak hiçbir konuda yeterli bilgi seviyesine ulaşamazlar. Çalıştıkları takımlara uyum sorunları yaşarlar ve çoğu kez verimli çalışma temposuna asla ulaşamazlar.
   4. Tek Açıdan Bilgilenme: Gününün büyük çoğunluğunu teknolojileri takip etmekle geçiren büyük ego sahibi kişilerin içine düştüğü durum. Bu tür kişiler büyük egoları nedeniyle “her şeyi ben bilirim” havasına sahiptirler. Ancak deneyimsiz olmaları ve teknik ve ürün bilgilerinin olmaması nedeniyle çalıştıkları projeye ya çok az katkı yaparlar, ya da katkıları tahmin edilenin aksine çok vasat kalır. Olayları tek yönlü görme eğilimleri ve üzerinde çalıştıkları projelere yaptıkları az katkı nedeniyle takım içerisinde negatif bir hava yaratırlar.

Yıllar içerisinde bizim de her bir maddeyi yaşayarak deneyimlediğimiz bilgi yönetiminde yaşanan sorunlar şöyle özetlenebilir.

1. Bilginin Kaybolması Sorunu: Kişiden kişiye aktarılan bilginin bazı bölümleri hiç aktarılamaz ya da eksik aktarılır. Bilginin deneyimlere dökülemediği, sadece kişiden kişiye aktarıldığı durumlarda, şirket içerisinde zaman içerisinde belli konuları bilen kişi kalmamaktadır. Çoğunlukla geliştirilme süreci tamamlanan ve bakım süreci devam eden projelerde yaşanır. Destek kalitesinde ciddi düşüşlere neden olduğu gibi, bilginin yeniden kazanılması için gereken çaba çok maliyetli olur.
2. Uzmanlaşamama Sorunu: Yeni katılanların projeye, takıma ve şirkete uyumunda ciddi problemler yaşanmasıdır. Özellikle platform ya da teknik bilgisi eksik yeni katılanların kendileri için tasarlanmış bir iç-eğitim almamaları durumunda, ya da takım arkadaşlarından yeteri kadar destek alamamaları durumunda yaşanır. Yeni katılanların tam randıman ile çalışabilmeleri aylar hatta yıllar alabilir. Bazı durumlarda çalışan hiçbir zaman geliştirilen uygulamaya hakim olamaz ve tam anlamıyla uzmanlaşamaz. Konuyu detayları ile bilemedikleri için, geliştirilen yazılımın kalitesinde ciddi düşüşler yaşanabilir. Yeni katılan çalışanların projelere aktif olarak dahil edilmesi durumunda, yazılım sürecini yavaşlatan unsurlar haline dönüşebilirler. Uzmanlaşamamak ve projeye tam anlamıyla dahil olamamak çalışanın moral ve motivasyonunda düşüşlere neden olabilir.
3. Bilginin Belli Kişilerde Birikmesi Sorunu: Bazı çalışanların, bazı önemli bilgilerin bilerek ya da bilmeyerek kendilerinde saklı kalması sebebiyle vazgeçilemeyen kişi, abartılı bir tabirle “tanrı çalışan” olmaları durumudur. Bu tür çalışanlar kurum için büyük bir tehlikedir, zira yaptıkları herhangi bir hatayı tespit edecek, ya da yapılan hatayı çözecek başka biri bulunmamaktadır. Vazgeçilmez olabilmek adına bilgi saklamayı tercih eden tanrı yazılımcılar süreçlerin yavaş işlemesine, hata oranının artmasına ve iş kalitesinde düşüşe neden olurlar ve çoğu zaman çalıştığı kurum üzerinde baskı kurarak etik olmayan tavırlar sergilerler. Uzun süre aynı projelerde çalışan kimi yazılımcılar bilgi paylaşımında yaşanan ciddi sorunlar nedeniyle zamanla tanrı yazılımcılara dönüşebilirler. Ağır iş yükü, yetiştirme stresi ve adil olmayan iş bölümü nedeniyle ciddi motivasyon problemleri yaşayabilirler.
4. Ustalaşmadan Uzmanlaşma Sorunu: Teknik bilgisini zaman içerisinde geliştirmeyen, sadece üzerinde çalıştığı ürün üzerinde uzmanlaşan çalışanların içine düştükleri tuzaktır. Çalıştığı konulara tüm detayları ile hakim olmak ve uzmanlaşmak kötü değil, aksine çalışan için çok iyi bir özellik. Ancak dünyadaki gelişmeleri takip etmeyen, uzmanlık dışı konularda da teknik deneyim ve becerileri oluşturamayan bireyler büyük resmi görmede sorunlar yaşarlar, farklı ihtiyaçlara karşı esnek çözümler üretemezler ve “sahip olduğun tek şey çekiç ise herşey sana çivi gibi görünür” atasözündeki gibi saplantılı bir algıya sahip olurlar.
5. Aşırı Belgeleme Sorunu: Bilgi paylaşımını herşeyi belgeleme olarak gören kurum ve kişilerin içine düştükleri durum. Kurumsal firmalarda zaman zaman karşılaştığımız bu durum, bireyler arası iletişim eksikliğini de göstermesi açısından önemlidir. Oluşturulan belgelerin çoğunluğunun bir süre sonra geçersiz olması nedeniyle genelde göstermelik bir iş olarak algılanır. O nedenle kimsenin okumadığı, birileri okusa da kısa bir süre sonra geçerliliğini yitirecek bir belgeyi oluşturmak başlı başına çalışan için bir yük olmaktadır.
6. Bilginin Aracılarda Erimesi Sorunu: Bilginin bir kişi ya da takımdan iletilmesi gereken hedef kişiye ya da takıma ulaşıncaya kadar türlü aracılardan geçmesi durumu. Müşteriden yazılımcıya doğrudan yapılacak bilgilendirmenin olumlu etkilerinin, yönetimsel katmanlarca ya da eposta gibi doğrudan olmayan iletişim ortamlarınca emilmesi ve verimsizliğe yo açması bir örnek olarak gösterilebilir. Aracılar üzerinden iletişim kurulan süreçlere sahip kurumlar, yanlış anlamalara ve olası hatalara açıktırlar. Çoğunlukla geliştirme süreci çok yavaş ve verimsiz işler.

Yukarıda listelemeye çalışılan sorunlar bazen teknik ya da ürün bilgisi eksikliği sebebiyle oluşurken, bazen de kişiler arası iletişimde, iş yapış şekillerinde, çalışanların kişiliklerinde yaşanan problemlerden doğmuştur. Bu sorunlardan her çalışan, takım ve kurum sürdürülebilir başarı uğruna mutlaka kaçınmalıdır. Bunu farkeden yazılım dünyasının tanınmış isimleri 2001 senesinde oluşturdukları Çevik Yazılım Geliştirme Manifestosu ile önemli noktalara parmak basmışlardır. Manifestoda “süreçler ve araçlardan ziyade bireyler ve etkileşimlere” değer verilmesi gerektiğini belirtmişlerdir. Bu da bilgi yönetimi ve bireyler arası iletişim ve paylaşımının ne kadar önemli olduğunu belirlemesi açısından ilgi çekicidir.

Bilgi Paylaşımı Kültürü

İnsan odaklı değerlere sahip çevik yazılım geliştirme prensipleri, iyi yazılımların iyi çalışanlar tarafından geliştirilebileceğine inanır. Bu nedenle çevik kurumlarda bireylerin gelişimi ve bireyler arası iletişim becerilerinin arttırılması öncelikli hedeflerdendir. Bilgi paylaşımı kültürünün kurum içerisinde oluşturulması, hem bireylerin bilgi ve becerilerinin artması, hem geliştirilen yazılımların belli kalite standartlarına sahip olması, hem de kurumun zaman içinde oluşan değişimlere ayak uydurabilmesini sağlaması açısından çok önemlidir. Bilgi paylaşımı kültürü, kurum içerisinde her türlü bilgi, beceri ve tecrübenin çalışanlar arası iletilmesini amaçlar. Bilgi paylaşımı kültürünün faydalarını şöyle sıralayabiliriz.

1. Yeni katılanlar takımlarına ve projelere daha hızlı uyum sağlarlar.
2. Çalışanlar bilgi ve becerilerini sürekli geliştirdikleri için geliştirdikleri ürünler kalite standartlarına uygun olur.
3. Takım içi yardımlaşma artar ve takım ruhu oluşur. Takımlar çok daha zorlayıcı problemlere sistematik bir şekilde yaklaşırlar ve bilgi birikimi takım içerisinde yayıldığı için olası sorunlara daha hızlı cevap verebilirler.
4. Takım içerisinde herhangi bir konuya ve detaylarına birden fazla kişi hakim olur. Bu da kimsenin bilmemesine bağlı oluşan olası ciddi hataların önüne geçer.
5. Projelerin başarısı belli başlı birkaç kişiye endeksli olmaz. Şirkette işten ayrılmalar durumunda çalışanlar eski verimliliklerine daha hızlı ulaşırlar.
6. Çalışanlar bilgi ve deneyimlerini paylaşmak için istekli olurlar. İnsan önünde konuşmaktan ve bildiklerini paylaşmaktan çekinmezler.
7. Takım içi ve takımlar arası işbirliği arttığından daha büyük ve karmaşık sistemlerin tasarlanması sırasında çok daha az sorun yaşanır.
8. Takımca başarı bireysel başarıdan daha önce gelir. Gelişmeye açık alanlar işbirliği ile hızla kapatılır.

Öğrenmeye ve öğretmeye hevesli birey sayısı çoğaldıkça yukarıda saydığım faydalar çok daha hızlı, çok daha etkili bir şekilde gerçekleşecektir.

Bilgi Paylaşım Pratikleri

Bilgi paylaşım kültürünü kurum içerisinde oluşturmak ve sürdürülebilir kılmak için birçok pratik mevcuttur. Bu pratiklerin ortak özellikleri şöyle sıralanabilir.

1. Gönüllülük: Uygulamalara katılım gönüllülük esasına dayanmalıdır.
2. Uyarlama: Uygulamaların verimliliği sürekli gözlemlenmeli, katılımcıların geribildirimlerine göre yeniden uyarlanmalıdır.
3. Süreklilik: Uygulamaların belirlenen sıklıkta devamlılığı sağlanmalıdır.
4. Eğitim: Her bir uygulamanın amacı çalışanlara anlatılmalı, planlı oturumlar ile nasıl gerçekleşeceği örneklendirilmelidir.

Çevik yazılım geliştirmenin çoğunlukla sadece projelendirme ve mühendislik uygulamalarından oluştuğu düşünülür. Projelendirme ve yazılım geliştirme alanlarında çevik pratiklerin kullanılmasının yanında kurum içinde çevik kültürün inşası, ölçülebilir ve sürdürülebilir bir yazılım geliştirme süreçlerinin oluşturulması, bilgi paylaşımının yaygınlaştırılması konuları da ayrı ayrı ele alınması gereken alanlardır.

Bilgi paylaşımı kültürünün oluşması amacıyla uygulanabilen pratikler şöyle sıralanabilir.

1) Öğle Arası Toplantıları (Brown Bag Sessions / Lunch and Learn Sesions)

Öğle arası toplantıları, öğle arasında bir toplantı odasında buluşan çalışanların, yanlarında getirdiği öğle yemeklerini yerken gerçekleştirdiği bilgi paylaşımı odaklı toplantılardır. Çoğunlukla üniversite ve devlet kurumlarında yapılan araştırmaların paylaşılması amacıyla gerçekleştirilen bu etkinlikler zamanla teknoloji üreten kurumlarda bir hayli popüler olmuştur. Genel kuralları şöyle sıralanabilir.

1. Bir ya da bir kaç konuşmacı bir konu üzerinde konuşma yaparlar. Konu kısıtlaması yoktur.
2. Toplantıda önceden hazırladıkları bir sunumu takip edebildikleri gibi, bazen de doğrudan kaynak kodu açarak etkileşimli bir eğitim verebilirler.
3. Amaç sadece ve sadece bilgi paylaşımı olduğundan toplantılara katılım gönüllük esasına dayanır.

Çalıştığım kurumlarda uzun süredir devam eden bu toplantılar için “haftada bir yapılan iç eğitimlerle çalışanlar iş arkadaşlarını eğitiyor” demek yanlış olmaz. Uygulama sırasında yaşadığımız deneyimler ışığında tanımladığımız ekstra kurallar ise şöyle sıralanabilir.

1. Yazılım takımlarında çalışan herkesin en az bir konuda eğitim yapması zorunludur. Bunun birinci kural olması, kurumun çalışanına verdiği önemi ve çalışanın bilgisine güvenildiğini göstermesi açısından önemlidir.
2. Eğitim herhangi bir konu üzerinde olabilir. Teknik konular olabileceği gibi, sosyal konular da konuşulabilir. Mutlaka son teknolojiler konuşulmak zorunda değil. Toplantı sırasında dinleyiciler birçok konuyu ne kadar yüzeysel bildiğini farkedecektir.
3. Eğtim konusu, geliştirdiğiniz ürünler ve yazılımlar da olabilir. Bilindiği üzere çalışanlar işten ayrıldığında bilgi de onlarla beraber ayrılıyor. Ürün, uygulama, proje hakkında bilgi zamanla azalıyor ve bazen kayboluyor. Bunu engellemek için, bu tür eğitimlerde üzerinde çalışılan projelerden de bahsedilebilir, gerek proje takımına gerekse başka takımlara bu bilgiler aktarılabilir. Ayda ya da iki ayda bir yapılan ürün temalı toplantıların çok faydalı olduğu gözlemlenmiştir.
4. Toplantılar, her hafta çarşamba günleri öğle arası ya da öğleden sonraki ilk saat gerçekleştirilir. Haftanın başı ve sonu çoğunlukla yoğunluğun en çok olduğu zamanlardır. O nedenle aksi belirtilmedikçe toplantıların çarşamba günleri yapılması sürekliliğin korunması açısından da önemlidir. Öğle arası katılımın düşük kalması durumunda, öğle arasından sonraki ilk saatlerde yapmak katılımı arttıracaktır.
5. Toplantının süresi 1 saattir. Konuşmacı gerek duyarsa en fazla yarım saat uzatabilir.
6. Her ayın son haftasında gelecek ayın toplantı takvimi netleşir. Yani eğer konuşmacılar konuşmasını ertelemek isterse ayın son haftasına kadar başvurabilir.
7. Konuşmacı onayı olmadan takvim kesinlikle netleşmez.
8. Toplantı takviminin bilinirliği, gerek eposta ile, gerek de çıktısı alınıp duvarlara asılarak arttırılmalıdır.
9. Toplantı için büyük bir oda, bir yansı cihazı, gerekirse internet bağlantısı ve bolca koltuk gereklidir.
10. Toplantının başlamasından 2 saat önce hatırlatma mesajı atılır. Eğer eğitim öğleden sonranın ilk saatlerinde yapılıyorsa, araya öğle yemeği gireceğinden son 15 dakika kala hatırlatma işe yaramayacaktır. Bu nedenle öğleden önce hatırlatma mesajını atmak faydalı olacaktır.
11. Eğitim bittikten sonra sunum ve varsa eğitim materyali eposta yoluyla dinleyicilere gönderilir.
12. Eğer bu tür etkinliklere ilk kez başlayacaksanız, ilk 2-3 eğitimi iyi planlamış olmanız gerekir. En başta verilen kaliteli eğitimler hem yeni konuşmacılara örnek teşkil eder, hem de çalışan motivasyonunu arttırır.
13. Toplantılarda konuşmacı olanlar, eğitim verebilmek için hem bilgilerini daha da arttırmak durumunda kalırlar, hem de herkesin önünde konuşma deneyimi yaşarlar. Bu konuşmacılara ekstra bir motivasyon verir. Dinleyiciler ise birbirinden farklı onlarca konuda fikir sahibi olurlar ve vizyonlarını arttırırlar. Yani iç eğitimler ile her iki taraf da kazançlıdır.

Öğle arası toplantılarının sürekliliği için yönetim desteği şarttır. Bu uygulama genelde kabul görünceye dek toplantılara katılım zorunlu tutulabilir.

Çalıştığım kurumlarda son 5 sene zarfında, son 45 tanesi son 45 haftada olmak üzere 60’den fazla öğle arası toplantısı gerçekleştirildi. 45’den farklı şirket çalışanı ve farklı şirketlerden 3 kişi konuşmacı oldular. Şirket dışından gelen misafir konuşmacıların öğle arası toplantıların popülerliğini arttırdığı gözlemlenmiştir. 15 yazılımcı arası yapılan bir ankette katılımcıların tümü bu toplantıları verimli bulduklarını, motivasyonu arttırıcı bir unsur olarak gördüklerini ve gelecekte konuşmacı olmak istediklerini belirttiler. Bu da doğru yolda olduğumuzun bir göstergesi olarak düşünülebilir.

2) Aydınlanma Konuşmaları (Lightening Talks)

Çok kısa bir biçimde 5-10 dakikalık kısa konuşmalar olarak tanımlayabileceğimiz aydınlanma konuşmaları, ilk kez 1997’de Python konferansında denenmiştir. Uzun sürmemesi, hem dinleyiciyi sıkmaması hem de konuşmacıları yormaması, konuşmacının vermek istediği mesajı kısa sürede verebilmesi, kısa süre içesinde onlarca farklı konuya değinilebilmesi nedeniyle hızla popülerlik kazandı. Hemen hemen her konferansta karşılaştığımız bu tip oturumlar, artık teknoloji üreten şirketler tarafından da gerçekleştirilmeye başlandı.

Çok az sayıda kuralı barındıran aydınlanma toplantıları şöyle detaylandırılabilir.

1. Toplantı ayda bir, ya da birkaç ayda bir 1 saat sürecek şekilde planlanmalıdır.
2. Bölüm, rol ya da görevden bağımsız herkes konuşmacı olabilir.
3. Her konuşmacının 5 dakika süresi vardır. 5 dakika sınırlamasına özellikle riayet edilmesi gerekir.
4. 1 saatlik bir oturumda 10 farklı konu ve konuşmacı yer alabilir.
5. Konu sınırlaması yoktur. Ancak konu dinleyicilerin ilgisini çekebilmeli, dinleyicileri aydınlatacak bakış açıları kazandırabilmelidir.
6. Konular düzenleyici komitenin onayı ile listeye alınırlar. O nedenle konuşmacı olmak isteyenlerin konuları ile başvurmaları gerekmektedir.
7. Herhangi bir yansıya izin verilmez. Bazı durumlarda, konuşma sırasında mutlaka ekrana yansıtmak istenirse, 3 yansıya kadar kabul edilir.
8. Bir konuşma bittiğinde diğeri başlar. Soru cevap bölümü yoktur. Sorusu olanlar tüm oturumun bitmesini beklemek durumundadır.

Sadece yazılım geliştirme bölümünün değil, farklı bölümlerin de yoğun ilgisini çeken aydınlanma toplantılarının, sürdürülebilir kılındığı takdirde kurum kültürüne kalıcı olumlu bir etki bırakacağını düşünüyoruz. Öğle arası toplantıları başarılı bir şekilde ile uygulanır ise, aydınlanma toplantılarının daha hızlı kabul göreceğine eminiz. Aydınlanma toplantıları yakın bir zaman içerisinde çalıştığımız kurumda başlayacaktır. Şirketteki farklı bölümlerden edindiğimiz geribidirimler çok olumlu, bizleri teşvik edicidir.

3) Kod Gözden Geçirme

Yazılımın kalite standartları açısından olmazsa olmaz maddelerin başında “bir başkası tarafından gözden geçirilmemiş kod canlıya çıkamaz” gelir. Bu kural bilgi paylaşımı kültürü oluşturmadan başarılamaz. Bu nedenle yazılım geliştirme süreçleri bu kurala uyacak şekilde tasarlanmalıdır. Kod gözden geçirme birinin yazdığı kodun başkaları tarafından incelenmesi demektir. Kişilerin bilerek ya da bilmeyerek yapabilecekleri hataları önlemesi ve geliştirilen yazılımın takım içerisinde bilinirliğini arttırması açısından çok önemlidir.

Kod gözden geçirme etkinliği, yapılan işin tam anlamıyla bitmiş (done) olabilmesi için gerekli adımlardan biri olarak belirlenmelidir. Her takımın belirlediği “bitti’nin tanımı (definition of done)” içerisine “yazılmış kodun gözden geçirilmiş olması” adımı eklenmelidir. Süreçlere bir kere eklendikten ve takım olarak belirlenmiş kurallara uyulduktan sonra yapılan işin kalitesinde dramatik bir artış gözlenmesi mümkündür.

Kod gözden geçirme birkaç türlü yapılabilir.

1. Bir araç aracılığıyla: Atlassian Crucible ya da GitHub gibi araçlar aracılığıyla yapılan commit’ler incelenebilir, programlayan kişiye bu araçlar üzerinden yorum yazılabilir.
2. Programcının kodu tüm takım üyelerine anlatması şekliyle: Kısa zamanda yüklü bir geliştirme yapılması, bir araç kullanmak istenmemesi ya da hemen geribildirim ihtiyacı duyulması durumunda sıklıkla tercih edilen bir yöntemdir.
3. Eşli programlama yaparak: Eşli programlama yaparak geliştirilen yazılımlar doğası gereği bir kişi tarafından yazılmazlar. Birden fazla kişi aynı kod üzerinde çalıştığı için kod ister istemez başkaları tarafından gözden geçirilmiş olur.

Daha verimli kod gözden geçirme yapabilmek için dikkat edilmesi gereken kaideler vardır. Bu noktaların ortaya çıkarılması, detaylandırılması ve tüm bu bilgi ve tekniklerin çalışanlara iç eğitimlerle anlatılması gerekidir. Çalıştığım kurumlarda kod gözden geçirme yöntemlerinin hepsi farklı takımlar tarafından benimsenmiş, yazılım geliştirme süreçlerine bir adım olarak dahil edilmiştir. Çoğunlukla yazılımcıların isteksiz olduğu bu alanda, çalışanlar ile özel olarak ilgilenilmekte, kod gözden geçirme araçları ve oturumlarının nasıl daha verimli kullanılabileceği konularında araştırmalarımız devam etmektedir.

4) Çevik Belgeleme (Agile Documentation) ve Çalıştırılabilen Şartname (Executable Specifications)

Şirketlerin içine düştüğü sorunlardan biri de çalışanlarını gereksiz detayda belgeleme yapmaya zormaktır. Çoğunlukla geleneksel yöntemlerle yazılım geliştiren kurumlarda, projelerin başında tüm detayların ayrıntıları ile bulunduğu şartnameler imzalanır. Bu şartnameler ve diğer tüm belgeler değişen şartlar ve gereksinimler nedeniyle kısa sürede eskirler ve geçersiz hale gelirler.

Detaylı belgelemenin gereksizliğini farkeden çalışanlar ya düşük kalitede belge üretirler ya da hiç belgelemezler. Bu da bilgi aktarımında önemli bir yeri olan belgeleme adımının aksaması anlamına gelir. Belgeleme süreçlerinde ciddi bir reforma ihtiyaç vardır. Bu reform 2 yeni kavramı doğurur: Çevik Belgeleme ve Çalıştırılabilen Şartnameler.

Çevik Belgeleme (Agile Documentation)

“Yeteri kadar belgeleme” olarak da adlandırılabilen çevik belgeleme, hedefe uyun belge yazma işlemidir. Önerdiği en beğenilen pratikler şöyle sıralanabilir.

• Hazırlayacağınız yazının hedef kitlesini iyi belirleyin. Müşteri, müdür, iş bölümü yada yazılımcı olabilir. Okuyucu kitlesini belirlemeniz belgelerken ne oranda detaya ineceğinizi belirlemenize yardımcı olur. Yeteri kadar bilgi vermek en öncelikli hedefimiz olmalı.
• Paragraflar dolusu yazı yazmak yerine kısa cümleler ve bolca grafik ve tablo kullanın. Yazılımın detaylarını cümlelere dökmek yerine akış diyagramları ve tablolar çok daha faydalı olacaktır.
• Okuyucunuza “eksik bilgi var mı” sorusu yanında “senin için daha okunaklı nasıl yazabilirdim” sorusunu da sorun. Eminim “şu bilgileri şu biçimde verseydin daha anlaşılır olurdu” ya da “şu bölümlere gerek yoktu” geribildirimlerini duyacakınız.
• Birçok belgeniz eskiyecek ve atıl duruma düşecek. Bundan kaçış yok. Eski ve kullanılmayan belgelerinizi ya güncelleyin, ya tamamen silin, ya da arşivleyin. Sakın güncel belgelerinizle aynı mekanda bırakmayın.
• Wikinizde mutlaka güncel tutmakla sorumlu ve zorunda olduğunuz bir bölüm bulunsun. Burada sadece ve sadece güncel belgeleri tutun. Her fırsatta da buradaki belgeleri güncelleyin. Böylelikle güncelliğinden emin olduğunuz belgelerin varlığı ile huzur duyacaksınız.
• Belgelere içeriği tam anlatan isimler verin. Gazete başlıkları gibi isimler bulunmayı zorlaştırır.
• Yeni belgeler oluşturmaktan korkmayın. Belge çöplüğü oluşamaması için belgenizi mutlaka doğru kategori altına yerleştirin.
• Grafik çizdiyseniz ve sayfanıza yerleştirdiyseniz, mutlaka kaynak dosyasını da belgeye ataçlayın. Böylelikle günler sonra belgeyi güncellemek gerektiğinde aynı grafik üzerinde değişiklik yapabilirsiniz.
• Gözünüze çarpan eskimiş belgeleri eğer güncelleyebiliyorsanız güncelleyin. Yoksa boşuna uğraşmayın, daha önce dediğim gibi silin/arşivleyin gitsin.
• Yazılımcılar da dökümantasyon yapar. Özellikle tasarımı, işlevleri ve akışları anlatan grafiklerle, test sonuçlarını ve verileri içeren tablolarla. Belgelemeden kaçmayın, bilakis özen gösterin. Siz bile bundan 2 hafta sonra neyin nasıl çalıştığını hatırlamak için kendinizi hazırladığınız belgelere bakarken bulacaksınız.

Genel kanının aksine çevik yazılım geliştirme pratikleri arasında belgeleme önemli bir yerde bulunur. Önemli olan verimli, faydalı ve hedefe odaklı belgeler yaratabilmektir.

Çalıştırılabilen Şartnameler (Executable Specifications)

Test güdümlü yazılım geliştirme (TDD), bir yazılım geliştirme yönteminden ziyade yazılım tasarlama yöntemi olarak Kent Beck tarafından 2001 senesinde ortaya atıldı. TDD’nin temel olarak uygulama kodundan önce test kodunun yazılması, sonra testi geçirebilecek miktarda uygulama kodunun yazılması ve en son olarak da uygulama ve test kodlarını yeniden düzenlenmesi basamaklarından oluşur. Bu basamaklar yazılım geliştirme süresince sayısız kez tekrarlanır. Bu yöntem sayesinde elimize iyi tasarlanmış, test edilebilir, esnek ve genişleyebilir bir yazılım ile yan ürün olarak testler kalır.

Birimleri ya da modülleri test etmek yerine, zaman zaman gereksinimleri bir bütün olarak test etmek isteyebiliriz. Yazacağımız bu tür testlere “gereksinim/davranış kabul testleri”, bu tür testleri baz alan yazılım tasarım yöntemine ise kullanıcı testi güdümlü yazılım geliştirme (ATDD) ya da davranış güdümlü yazılım geliştirme (BDD) denir.

Her ne tip olursa olsun, elimize geçen testlerin tümü uygulamamızın çalışma şartnamelerini oluşturur. Bu testler istenildiği zaman çalıştırılabilir ve uygulamanın doğru çalışıp çalışmadığı gözlemlenebilir. Testlerin hepsinin başarılı olarak geçtiğini gördüğümüzde uygulamamızın doğru çalıştığını düşünebiliriz.

Yazılım takımlarında, uygulamanın teknik detayları ile alakalı genel akışı ve tasarımı anlatan belgelerden başka bir belgenin üretilmesine ihtiyaç yoktur. TDD ve/veya ATDD/BDD ile geliştirilen yazılımlarda işleyiş ile alakalı belgeler testlerin kendisidir. Uygulamanın detayları testler incelenerek ve okunarak öğrenilebilir. Bu da elle yapılan testlerin sayıca dramatik olarak azalmasına, ürün ne kadar eskirse eskisin kodun korkusuzca yeniden yapılandırılabilmesine,

5) Çevik Toplantılar

Bilginin müşteriden takıma, takım içerisinde bireyden bireye ve hatta takımdan takıma aktığı toplantıların başında çevik kültürün ayrılmaz parçası olan çevik toplantılar gelir. Her iterasyon başında yapılan planlama toplantısı, her sabah 15’şer dakika süren günlük ayakta Scrum toplantıları ve her iterasyon sonrası yapılan öz-değerlendirme toplantıları bilgi paylaşımı için önemli fırsatlardır.

Her iterasyon başında yapılan planlama toplantısında müşteriden takıma nasıl bir yazılım istediği ile alakalı doğrudan bilgi aktarımı yapılır. Sabahları yapılan 15’şer dakikalık ayakta toplantılar ile takım üyeleri birbirlerine bilgi aktarımında bulunurlar. Öz-değerlendirme toplantıları ise takımın kendini sorguladığı ve iyileştirilecek noktaların çıkarıldığı toplantılardır. Her üç toplantı da çevik takımlarda bilgi paylaşımı için gereken en önemli etkinliklerdendir. Scrum uygulayan, uygulamayan çalıştığım hemen hemen her takım bu toplantıları uygulamaya özellikle dikkat etmişlerdir. Takım tarafından gelen geribildirim çok olumlu, devamlı olması gerekliliği yönündedir.