Çeviklik, Scrum ve Biz

Çok komik. 🙂 Zaman zaman duyuyorum, IT yöneticilerinin “biz çevik sürece geçtik” ya da “artık çevik süreçler kullanıyoruz” gibisinden cümlelerini. Hemen şunu soruyorum ya da içimden geçiriyorum: “Daha önce neyi kullanıyordunuz ki???” 🙂 Öyle ya bildiğime göre taa Orta Asya’dan bu yana bizde kervan yolda düzülüyor. Yüzyıllardır zaten çevik hatta aşırı çevikiz. O kadar çok heyecanlıyız ve aklımız heyecanımıza o kadar çok yenik düşüyor ki birisinden bize bir iş yapmasını istediyip de bir süre sonra “düşünüyorum” cevabını alırsak çoğunlukla “düşünme yap” ya da “aptal mısın neyini düşünüyorsun?”  şeklinde laflar ediyoruz. İşin tuhafı, yazılım geliştirme gibi son derece soyut ve aşırı değişken çıktıları olan bir disiplinde de benzer şekilde kervanın yolda düzüldüğünü düşünmemiz. Tabi tüm bunlar birer kültür meselesi. Yazılım geliştiren ya da yöneten kişi, örneğin milli takımmızın Hollanda maçında bir mucize bekliyor. Zaten Çeklere karşı 3-2’lik mucizeyi de biz gerçekleştirmiştik. Olaylara bakışımız, toplumun hangi katmanından gelirsek gelelim aynı açıdan yani, sistematiklik yerine gelişi güzellik, takım yerine tek tek kişilerin kurtarma becerilerine odaklı, uzun vadede bir şeyleri yerleştirip başarmak yerine tamamen random, rastgele, ne zaman olacağı belli olmayan çıkışları beklemek. Yazılımı da bu şekilde ele alıyoruz genelde. Dolayısıyla diyorum ki bize sadece “çeviklik” değil “disiplin” de lazım. Bize “agility” değil “process-orientedness” lazım daha çok, yani kimin ne yapacağının belli olduğu, iyi tanımlandığı yazılım geliştirme süreçleri gerekli diye düşünüyorum.

Ne demek istediğimi bir örnekle anlatmaya çalışayım. 15 yılı aşkın süredir iş yazılımları geliştiren bir şirkete danışmanlık veriyorum. Zamanında bu şirketin yazılım müdürlüğünü de yaptığımdan 15 yılda nereden nereye geldiklerini çok iyi biliyorum. Ben şirketten ayrılırken 45-50 kişilerdi, şimdi ise 150’ye dayandılar sanırım. Sirketi zamanında kurup tırnaklarıyla kazıyarak bu noktaya getiren kişiler uzun süre haklı olarak programcılarının, müşterilerinin sorunlarını çözmekte sıklıkla yetersiz kaldıklarından şikayet eder ve problemi “proaktif olmamak” ya da en azından “inisiyatif almamak, alamamak” çekirdek davranışına indirgerlerdi. Tamamen haklılardı. Çünkü son derece çekirdekteki iş uygulamalarını geliştiren bu kurumun çalışanlarının müşterilerinin problemlerini çözmede “iki eli kanda olsa bile” şeklinde bir davranışa sahip olması, müşteri memnuniyeti açısından son derece önemliydi onlar için. Dolayısıyla “agile” davranarak işe başladılar. Simdi ise büyüdüler, “analist-programcı-proje yöneticisi-tester” düzeninden PMP sertifikasına sahip proje yöneticilerinden oluşan proje yönetim ofisine, yazılım mimari gibi rollere sahip bir development grubuna, 30 civarında analistin olduğu bir analiz grubuna, yeni oluşturulmakta olan ap-ayrı bir tester yapısına ve İK, Finans vb destek birimlerine sahip, ülkemiz standartlarında kocaman bir yazılım evi haline geldiler. Ve geldikleri noktada artık sistematik olmak zorundalar, kaliteye daha fazla önem veriyorlar, çünkü sektörlerinde bu ülkede lider oldukları gibi yurt dışına da açılmaya çalışıyorlar. Ve artık yöneticileri örneğin developerlarının müşteriden gelen bir hata bildirimine balıklama atlamalarını istemiyor. O hatanın kayıtlara geçmesini, gerçek sebebinin bulunmasını, gerekiyorsa analizinin yapılıp, etki ve maliyet gibi bilgilerin ortaya çıkmasını, o anı kurtarmak yerine daha sağlıklı bir çözüm üretilip, bu çözümün gerekiyorsa tüm müşterilerde yaygınlaştırılmasını hatta bir sonraki sürümün parçası olmasını ve en önemlisi de bu bilgilerin ilgili herkes tarafından bilinmesini istiyorlar. Bu yüzden developerin bu döngüye girmeden hatayı kendi başına halletmeye kalkmasının, nihayetinde, hata halledilse bile doğru bir davranış olmadığını, belki müşterisini memnun edeceğini ama şirketi açısından sürdürülemez bir davranış olacağını, yine müşteri odaklı ama daha sistematik bir çözüm döngüsü içinde olmak gerektiğini çalışanlarına anlatmaya çalışıyorlar. Çalışanlarının kariyer planları ve mutlu olmaları üzerine daha fazla kafa patlatıyorlar. Eskiden eğitim harcamaları ancak zorunluluk durumunda ve pek çok kısıtla yapılabilirken şimdi her sene San Francisco’ya JavaOne’a 4-5 çalışanını gönderiyorlar, çalışanlarını elde tutmak ve daha mutlu ve üretken kılmak için “yetenek yönetimi” çalişmaları yapıyorlar.  Çünkü artık çok daha zor bir yönetim problemiyle karşı karşıyalar. Sadece çevik olmak yerine sistematik çeviklik istiyorlar. Bu amaçla analiz olsun tasarım olsun ya da development olsun, nasıl bir sürece sahip olmaları gerektiği üzerine birlikte kafa yoruyoruz. Risk analizi, bütçe çalışmaları, yıllık eğitim planı vb. çalışmalar çok daha önemli hale geldi artık. Hala çevikler ama artık daha çok disiplinli bir çeviklik var.

Ote taraftan çevikliği yukarıda olduğu gibi kelime manasıyla almak yerine bir yönetim felsefesi ya da yazılım geliştirme paradigması olarak ele aldığımızda, yani “agile processes” ya da “çevik süreçleri” düşündüğümüzde, pek tabi olarak yukarıda kastettiğimiz çeviklikten farklı bir noktada durduğumuz aşikardır. Bunu da şöyle açıklayabiliriz: Çevik süreç kavramı bizim ülkemizde çıkmadığı gibi bu paradigma çerçevesinde oluşturulan metodolojilere bir katkımız da henüz olmadı. Çevik süreçlerin temeli, ozellikle ABD’de aşırı yapısal ve bürokratik, bundan dolayı hantal ve müşteriden uzak yazılım organizasyonları ve onların yazılım geliştirmeye yaklaşımlarına bir tepki olarak yayınlanmış Agile Manifesto‘ya dayanır. Tabi olarak bu manifesto bir günde yayınlanmadı. Eskiden bu yana yazılımın başarısızlık ve başarısının neye bağlı olduğu üzerine kafa yoran pek çok akademisyen ve uygulayıcı vardı. Bunların en iyi bilinenleri Barry Boehm ve onun spiral modeli ile Kent Beck’in Extreme Programming’idir. Benzer şekilde Jim Highsmith’in yazılarını, bu konudaki itirazları ve çözüm önerilerini okuduğumu hatırlıyorum. Bu anlamda 90lı yıllarda Unified Process gibi, yazılım projesini bir seferde bir big bang gibi kurmak yerine daha daha müşteri odaklı, mimariyi merkeze koyan ve riski önceleyen metodolojiler konuşulmaktaydı. Agile Manifesto da bu dünyanın babaları tarafından, ağır süreçler yerine insanları ve iletişimi, hantal ve okunmayan dokümanlar yerine yinelemeli ve artımlı (iterative, incremental) olarak geliştirilen, her an çalışır halde tutulan ve müşteri tarafından test edilebilen kod yapısını, müşteride analiz yapıp, “2 sene sonra kullanıcı kabul testinde görüşelim” diyen anlayış yerine, müşteriyle yakın ilişki içinde olan, onu da elini taşın altına koymanın en temel risk yönetimi olduğunu düşünen bir paradigmayı, proje planını kutsamak yerine değişimi nasıl yöneteceğini düşünen bir felsefeyi dünyaya duyurdu. Çok da iyi oldu, özellikle de bizim için. Neden? Çünkü bizim zaten genlerimizden, kültürümüzden, alışkanlıklarımızdan ve aşırı faydacı ve anlık yapımızdan dolayı çok daha uzunca bir müddet o hantal ve aşırı bürokratik yazılım geliştirme metodolojilerini uygulamamız mümkün değildi. Bu yüzden çevik süreçler, bu hantal süreçlere sahip yazılım evlerine dinamizm getiriken bize sistematiklik getirdi. Ne kadar sistematiklik? Tam olması gerektiği kadar bence? Fazlası değil, çünkü fazla sistematiklik bize göre değil. Bu anlamda çevik süreçler, bizim gibi bir kaç bin senedir çevik yaşayanlara disiplin sağlayor, ben de bu yüzden yukarıda “disiplinli çeviklik”i kullandım.

Agile Manifesto’ya imza atanlardan birisi de Jeff Sutherland aynı zamanda Scrum’ın da yaratıcısı. Yukarıda bahsettiğim o hantal yapıdan tamamen haberdar ve ona karşın daha çevik ama gerektiği kadar sistemli bir yazılım geliştirme yönetim metodoloji ortaya koymuş birisi. Scrum ülkemizde de yaygınlaşıyor ve ben buna çok seviniyorum. Bize disiplin getirirken damarlarımızda olan çevikliği ise övüyor ama onu sistematik olarak kullanmamıza imkan sağlıyor.

Bu blogun takipçilerinden olan bir dost ise bana gönderdiği bir emaille, Jeff Sutherland’in 16-17 Ocak 2014 tarihlerinde ülkemizde yapılacak Scrum Master eğitimi için İstanbul’da oalcağını hatırlattı. Scrum Turkey tarafından düzenlenen bu çalışmayla ilgili ayrıntılı bilgiye buradan ulaşabilirsiniz.

İçimizdeki çevikliğe zapt-u rapt vurmanın zamanı geldi de geçiyor bile 🙂

Toplam görüntülenme sayısı: 1221