Çevik Prensipler ve Veri Bilimi

İş zekâsında Scrum’ı duymadan önce bile Scrum benzeri yöntemlerle projeler yürüttüm. Scrum ile tanıştığımda, zaten olması gereken bu hissini yaşamıştım.
Ama formel olarak bu konuyu daha iyi incelemem gerekiyor. Bu inceleme kapsamında işin anayasası sayılabilecek bir kitap okuyorum: Kenneth S. Rubin’den Essential Scrum. Tabii ki benim olayım asıl veri bilimi üzerine etkisi…
Üçüncü bölümün sonunda özet olarak verilmiş Çevik Prensipleri veri bilimi açısından gözden geçirelim:
“Development isn’t manufacturing; development creates the recipe for the product.”
Bu prensip, geliştirmeyi üretimle karşılaştıran yaklaşıma muhalif. Ürün üretme değil, ürün geliştirme kavramı üzerinde duruyor. Veri biliminde de bu ilke aynen geçerli. Yapmak istediğimiz, öncelikle bir model geliştirmek. Tabii ki bu modeli üretimde kullanılmak üzere geliştiriyoruz. Modelin kullanılması üretim, modelin geliştirmesi ise ürün geliştirme gibi düşünülebilir.
“Development should be iterative and incremental.”
Çevik yaklaşımın ana prensiplerinden biri çevrimler halinde ilerlemek. Veri biliminde de bu kesinlikle zorunlu. Verinin içinde yer alan örüntüleri, örüntü olup olmadığını, varsa ne kadar güçlü olduğunu ve örüntüyü yakalayacak girdilerin neler olduğunu önceden kestirmek imkânsız. Her çevrimle birlikte yeni öğrendikleriniz, sonraki çevrimlerdeki yaklaşımınızı da etkiliyor hatta belirliyor.
“Leverage variability through inspection, adaptation, and transparency.”
Değişkenlikten kaçınmak mümkün değil. Değişkenliği temel alan bir geliştirme süreci zorunlu. Veride bulduğunuz yeni doneler, adımlı geliştirmede ara modellerle öğrendiğiniz bilgiler, taraflar arasındaki etkileşimle ortaya çıkan yeni yaklaşımlar… Bunların tamamı veri bilimi projelerinde geliştirmenin hızını da yönünü de etkileyebilecek konular. Ele aldığınız konuyu terk edip yakın başka bir probleme yönelmek zorunda bile kalabilirsiniz.
“Reduce uncertainties simultaneously.”
Geleneksel yaklaşım sonuçlarla ilgili belirsizliği ortadan kaldırıp sonra da araçlarla ilgili belirsizliklerle uğraşır. Oysa sonuca henüz çok uzakken, sonucun belirsizliklerini ortadan kaldırmak pek mümkün değildir. Sprint’ler boyunca sonuçların ve araçların belirsizliklerini birlikte azaltmak gerekir.
Veri biliminde bu ilke normal yazılım projelerinden çok daha fazla geçerli. Verinin kendisinde çalışmaları yapmadan önce nasıl bir sonuca ulaşacağınızı belirlemek tamamen bir hayal. Yönünüzü belirleyebilirsiniz ama veriyle çalışmadan sonucun belirsizliklerini ortadan kaldırmak olası değildir.
“Keep options open.”
Çevik yöntemlerde bir sonraki sprint’te ne yapacağınızdan emin olmazsınız. Gelişmelere göre Product Owner yapılacak işleri ve/veya önceliklerini değiştirebilir. Veri bilimi çalışmalarında da veriyi öğrendikçe, yeni girdiler buldukça, girdiler için veri zenginleştirmeler yaptıkça, ara modelleri çalıştırıp sonuçları gördükçe kararlarınız değişebilir.
“We can’t get it right up front.”
Başlangıçta neredeyse hiçbir şey bilmiyoruz. Veri biliminde her zaman olan durum budur. Sorunumuz var. Sonuçlar var. Girdiler var. Sorunumuzu çözmek için bu girdilerle bu çıktılar arasındaki ilişkiyi hemencecik doğruca bulabilecek olsak, zaten proje yapmaya ne gerek kalır ki!
Veri bilimi projelerini, zaten bilmediğimiz ilişkileri öğrenmek için yapıyoruz. O zaman hemencecik mükemmel bir sonuca ulaşamayacağımız aşikâr. Projenin aşamalarıyla umulur ki, yeterince güçlü ilişkiler yakalayıp yeterince işe yarar bir model geliştirebiliriz.
“Favor an adaptive, exploratory approach.”
Önceki ilkelerde yazdıklarım zaten bu ilkeyi de kapsıyor. Keşif amaçlı araştırma, veri bilimi işinin zaten ruhu.
“Embrace change in an economically sensible way.”
Değişim esastır. Her aşamada öğrendiklerimiz sonraki aşamalar için yolumuzu aydınlatabilir ve değiştirebilir.
“Balance predictive up-front work with adaptive just-in-time work.”
Problemimizi iyi tanırsak, veri bilimi problem tiplerine göre konumlamasını iyi yaparsak, benzer proje deneyimlerimizdeki süreç bilgilerinden yararlanırsak öngörebileceğimiz işler olur. Ama bir yandan da verinin kendisi kraldır ve oradan çıkan sonuçlar yönümüzde değişiklikler yapar. Bu iki tip çalışmayı da öngörüp dengeli bir şekilde yürütmemiz gerekir.
“Validate important assumptions fast.”
Veri biliminin doğal olarak içerdiği belirsizlikler içinde projeye başlarken varsayımlarla hareket etmek kaçınılmazdır. Ancak önemli varsayımları mümkün olduğu kadar hızlı teyit etmek gerekir. Özellikle verinin gerçek hayattaki karşılıklarıyla ilgili varsayımlarımızda umulmadık hatalar görebiliriz. Hatta varsayım değil de bilgi olarak kabul ettiğimiz şeylerin bile gerçekte bir karşılığı olmadığını görüp hayretler içinde kalabiliriz.
Mesela saha satış bilgilerini kullanarak satış noktalarının potansiyelini tahmin etmek istiyorsunuz. Acaba satış noktalarına ait gözüken fatura satırları, gerçekten o noktalara mı ait? Yoksa satışçılar faturayı düzenlerken bazen ortam şartları gereği bazı kaydırmalar yapıyor olabilir mi?
Ya da sipariş bilgilerini kullanarak gelecek talepleri tahmin etmek istiyorsunuz. Acaba sizin sipariş verisi olduğunu düşündüğünüz girdiler aslında tedarik bilgileri mi? Belki de elde stok olmadığı için siparişler gecikmeli tedarik ediliyor. Bu durumda tedarik bilgisini tahmin için kullanmak doğru olmayacaktır.
“Leverage multiple concurrent learning loops.”
Veri bilimi temel olarak bir öğrenme faaliyetidir. Ve proje süreciyle paralel olarak sürekli bir öğrenme süreci vardır. Bu süreç sık sık geri dönüşler ve yeniden ele almalar içeren çoklu bir yapıdadır. ​
12. ilkeyle devam ediyoruz:
“Organize workflow for fast feedback.”
Veri bilimi projelerinde elde ettiğimiz sonuçlara göre önceki adımlara ya da başa dönmek sıklıkla karşılaşılan bir durumdur. Bu dönüşler, daha iyi sonuçlar almak için son derece önemlidir. Geri beslemeleri hızlı yapmak, bu geri dönme çevrimlerinin çok daha hızlı gerçekleşmesini ve faydanın çok daha hızlı elde edilmesini sağlayabilir.
“Use smaller, economically sensible batch sizes.”
Öğrendikçe yeniden ele alma sürecinin bir başka gereği de, adımları kısa tutmak. Proje konunuza ve ilgili aktörlerin cevap hızına göre değişebilir ama iki haftalık sprintler ideal gibi duruyor. Hızlı cevap alabildiğiniz durumlarda bunu bire düşürmek de mümkün.
“Recognize inventory and manage it to achieve good flow.”
Üretimde nasıl hammaddeler ve başka çeşitli şeylerin stokları tutuluyor ve bu stokların iyi yönetilmesi gerekiyorsa, veri bilimi projelerinde de stoğu iyi yönetmek gerekir. Peki, nedir stok? Mesela çözmeye çalıştığımız soruna yönelik girdi bilgileri bir stoktur. Olası girdilerin tamamını toplayıp biriktirmeyi beklemeden, makul bir miktarı elde ettiğimizde model geliştirmeye başlayabiliriz. Stokun kalan unsurları geldikçe, yani başka girdiler de elimize geçtikçe modelleri yeniden ele alıp iyileştirmeye çalışabiliriz.
“Focus on idle work, not idle workers.”
İş yapacak kişilerin doluluğu yerine yapılacak işleri takip etmek önemli bir yaklaşım. Veri biliminin doğası gereği, çoğu projede çalışan ekiplerin yapması gereken başka işler de olacaktır. Çoğu veri bilimi projesinde, ilgili kişilerin pek çoğunun ana işi bu özel proje olmaz. Böyle bir durumda sürdürülmekte olan iş stoklarının zaman zaman bulundukları yerde takılıp kalması sık karşılaşabileceğimiz bir risktir. Kişileri takip etmekten çok, işleri takip altında tutmak önemlidir. Hangi işin takıldığını görürseniz, yürütmek için gerekli müdahaleyi yapabilirsiniz. Oysa kim boşta diye bakarsanız, hemen her kişinin (çoklukla da proje dışı işlerle) gayet dolu olduklarını görerek alarm durumunu fark etmeyebilirsiniz.
“Always consider cost of delay.”
Veri biliminde çoğu durumda işimiz tahminler üretmektir. 100 günde yüzde 95 isabetli tahminler üretmek mi daha iyidir sizce? Yoksa 20 günde yüzde 90 isabetli tahminler üretmek mi? İşin teorisine ve matematiğine çok gömülenler, bazen yüzde yarımlık iyileştirmeler için haftalarını vermekten çekinmezler. Bazı durumlarda işin gereği de zaten budur. Ama iş faydasını esas aldığınızda, çok daha kısa sürede isabeti daha düşük olsa da iş gören modeller üretmek çoğunlukla çok daha anlamlı olur.
“Adapt and replan rather than conform to a plan.”
Bundan bolca bahsettik zaten. Verideki örüntülerin neler olduğunu bilmiyoruz. Bu durumda planı da en baştan tam olarak yapıp ona aynen uymamız mümkün değil.
“Measure progress by validating working assets.”
Ürünü kullanacak iş birimlerinin karşısına aylar sonra çıkmayı düşünmeyin. Onların kullanımına sunulmadıkça, veri bilimi projenizin kâğıt üzerindeki ilerlemeleri anlamlı değildir. İş birimlerine sunulacak çalışır durumdaki bileşenleri erkenden oluşturmaya ve onları giderek geliştirmeye odaklanın.
“Value-centric – deliver the value.”
Çıktılar, çıktılar, çıktılar… Erken ve sık değer üretmeye odaklanmamız gerekir. Elimizdeki veri bilimi problemini birden fazla modele bölebiliriz. Her bir modeli giderek iyileşen iterasyonlarla yönetebiliriz. Erkenden ve sık sık artan değer üretimi veri bilimi projeleri için de esastır.
“Go fast but never hurry.”
Hızlı ve sık değer üretmeye odaklandığınızda, hatalarınız da daha erken ortaya çıkar. Ve onları düzelerek ilerleyebilirsiniz. Ama hatalarınız doğal öğrenme sürecine ilişkin olmalıdır. Düpedüz özensiz çalışmayı gerektirecek bir acele içinde hareket etmeyin.
“Build quality in from the beginning.”
Erken ve sık teslimler, en başlardan itibaren kaliteyi de geliştirme sürecinizin ayrılmaz bir bileşeni yapmanızı zorunlu kılar.
“Employ minimally sufficient ceremony.”
Protokol için çalışmayın, çalışmanızı anlamlı kılacak kadar protokol uygulayın.
22 çevik ilkeyi veri bilimi açısından küçük yorumlarla aktarmış oldum. Scrum ve veri bilimi konusunda başka yazılar da yazmayı umuyorum. Ama yazacak o kadar çok şey var ki…
Mesela kariyer yönetimi ve kişisel gelişimi de Scrum üzerinden yorumlamak çok ilgi çekici olabilir. İleride bu konuda bir kitap yazmayı da düşünebilirim.
Kariyer yönetimi ilginizi çekiyorsa, 24 Kariyer Tuzağı adlı kitabımı okuyabilirsiniz.​