Kurulum Projelerinde Çevik Yaklaşımlar

Architecht olarak 7 yıldır bankalara ve farklı finansal kurumlara BOA adını verdiğimiz bankacılık altyapısı sağlıyoruz. Son 3 yıldır da bu kurulum projelerinde çevik bir dönüşüm sürecinin içerisindeyiz. Müşterilerimize taahhüt edilen hizmeti zamanında ve en kaliteli bir şekilde verebilmek için uygulanması gereken proje yönetim biçimi üzerinde uzun çalışmalar yaptık. Önce bazı projeler ve ekipler için Scrum ile başladık, sonra Kanban’ı referans alarak hibrit bir yöntemle ilerledik. Çevikliğin en temel prensibi olan deneysellik yani deneyerek öğrenme, en doğrusunu bulma bizim için de geçerli oldu. Bu yolculukta 69 Sprint’i geride bırakırken yaşadığımız zorlukları ve edindiğimiz deneyimleri sizlere aktarmaya çalışacağım.

Şirketimizin amiral gemisi olan BOA’yı bir kurum için ayağa kaldırmamız gerektiğinde yolculuk özetle şu şekilde ilerlemektedir;

Kod, veri tabanı aktarımı ve temizliği,
Uygulamanın Architecht ortamlarında ayağa kaldırılması,
BDDK denetimine esas olacak 1. faz testlerinin yapılması, hataların çözülmesi,
Müşteri ortamlarının kurulması, (Dev, Test, Prod)
Bağımsız denetim firması ve müşteri ile senaryoların gerçeklenmesi,
BDDK denetim sürecine eşlik edilmesi ve destek verilmesi,
Müşteri iş birimleri ve BT personellerine eğitim verilmesi,
Faaliyet izni sonrası canlı ortam kurulumlarının yapılması,
Canlı ortama geçtikten sonra TCMB, KKB, Mernis, SWIFT gibi birçok kurumla entegrasyonların sağlanması,
Bakım destek hizmetlerinin verilmesi.

Scrum mı, Kanban mı?

BOA kurulum süreçlerimizde testlerin, hata çözümlerinin, destek hizmetlerinin dönem dönem ağırlık oluşturması nedeniyle, işlerin belirli bir bant düzeninde ilerlemesi, ekiplerin işleri çekerek belirlenen zamanda teslimatı yetiştirmesi kritik önem arz etmektedir. Scrum’un temelinde yer alan MVP modelinin bu işler için her sprint uygulanabilir olmaması, Kanban’ı bizler için alternatif bir yöntem olarak gündemimize taşımış oldu. Sözleşmelerin belirli takvim gözetilerek yapılması, müşterilerimizin kuruluş iznini takiben 9 aylık yasal süre içerisinde faaliyet iznine başvurma zorunluluklarının bulunması bu kararda başka etkenler olmaktadır. Ancak burdaki çerçeve değişikliği bizleri çevik yönetimin temel ilkelerinden uzaklaştırmamaktadır; ekip otonomisi, değişikliğe ayak uydurma, deneyerek öğrenme, inisiyatif alma, geri bildirimle gelişim eğrisini yukarda tutma, müşteri beklentisini yönetme.

Scrum ile Kanban arasındaki temel farklar

Scrum	Kanban
Sprint, iterasyon, çalışan parça üretimi önemli	Sürecin kesintiye uğramadan üretim akışının devamlılığı
Sprint başlangıcında planlama, taahhüt (commitment) ve sprint hedefi	Sürekli iş çekme, dinamik planlama (just-in time planning)
KPI (anahtar performans göstergesi) : Velocity	KPI : Teslim süresi (lead time), döngü süresi (cycle time)
Çapraz fonksiyonlu kişilerle bağımsız iş yapma kültürü	Akışta oluşan bağımlılıkları ve tıkanıklıkları yönetme becerisi
Tüm ekibin her işe story point şeklinde puan vermesi yaygın kullanım	İş büyüklükleri daha yalın (küçük, orta, büyük)

Teslimat (Delivery) ekiplerinde aslında her iş Kanban’a uygun şekilde olmamaktadır. Kurulum ve test işlerinin yanı sıra yeni geliştirmeler de yapılmaktadır. Bu durumda saf Kanban ya da Scrum uygulamak zorlaşmaktadır. Biz de bu nedenle adına hibrit diyebileceğimiz, ya da piyasada Scrumban gibi isimlendirmelerin olduğu bir şekilde kendimize özgü bir yöntem uygulamaya çalışıyoruz. Günün sonunda konu çevikliğin ana prensiplerinden taviz vermeden Scrum ve Kanban’ın bize sunduğu farklı çerçevelerden faydalanmak olarak özetlenmektedir.

Çevik modellerle ilerlerken karşılaştığımız konular ve uygulama yöntemlerine ilişkin bazı başlıklara daha yakından bakabiliriz.

Planlama

Hizmet verdiğimiz kurumlar arasında, kurulum aşamasında, denetim sürecinde, faaliyet izni sürecinde ve canlıda olanlar gibi farklı aşamalarda müşterilerimiz bulunmaktadır. Bu da her bir müşterinin ihtiyacını, önceliklerini dikkate alarak iş listesinin oluşturulması, ekiplere dağıtımının yapılması ve her sprint sonunda çalışan bir parçanın teslimatının yapılması anlamına gelmektedir. Bazen takvimlerin çakışması nedeniyle ekipler üzerindeki yoğunluklar artabilmekte, bu durumda ilk yöntem olarak proje yöneticilerinin müşterilerle iş planı ve öncelik yönetimi üzerinden tekrar geçmesi, Product Owner’lar ile tekrar hizalanması önem arz etmektedir. İzlediğimiz başka bir yöntem de sprintler içerisinde aldığımız işleri (Sprint Backlog) daha iyi yönetebilmek için kritik öneme sahip işleri Sprint Hedefi olarak belirleyip ekip odağını daha verimli yönetmek olmaktadır. Planlama konusunda önemli bir başlık da proje yöneticilerinin ekipler üzerindeki konumu, Product Owner’lar ile iletişimi ve hizalanmasıdır. Proje yöneticilerinin çevik dünyadaki yeri halen tartışılan bir konudur. Biz de Architecht olarak proje yönetiminin çevik takımlarla daha etkin ve verimli çalışabilmesi için efor sarf ediyor ve en doğru metodolojiyi yakalama konusunda çalışmaya devam ediyoruz.

Büyük Resme Odaklanma

Scrum’un en büyük handikaplarından olan biri büyük resme odaklanamama, bizim gibi sıkı takvime bağlı çalışan şirketler için bazı riskler barındırabilmektedir. Koşulan her sprint sonunda üretilen parçanın müşteri özelindeki büyük resmin neresine tekabül ettiği konusunda bir farkındalık kaybı yaşandığında oluşan risk de artmaktadır. Buradaki riski, fazlandırma yaparak azaltmaya çalışıyoruz. 15.000+ ekrana sahip BOA’nın kurulum süreçlerini, bir taraftan yatırım bankası, dijital banka ve diğer müşteri tipleri için farklılaştırarak, diğer taraftan BDDK denetimine esas olması gereken kısımlarla başlayıp faaliyet izni sonrası diğer başlıkları devreye alacak şekilde fazlandırarak yönetmeye çalışıyoruz. Büyük resim konusunda proje yönetim ekibimiz süreçleri yakından takip etmekte ve ekiplerle öncelik yönetimi konusunda hizalanmaktadır.

Ekipler Arası Uyum ve Ekip Dışı İle Çalışabilme

BOA kurulum süreçlerinde ekiplerin zaman zaman birlikte çalışması gerekmektedir. Her ne kadar planlama, ekiplere özel yapılsa da gerek planlama sırasında gerekse sprint içerisinde diğer ekiplerle yakın çalışma ihtiyacı ortaya çıkmaktadır. Hatta zaman zaman da ortak işler açılmaktadır. Bu durumda ortak çalışması gereken ekip üyelerinin kendiliğinden organize olarak iş kapsamında beklenen üretimi yapmaları önemli bir sinerji oluşturmakta ve ekipler arası iş birliğini artırmaktadır. Burda korumacı yaklaşımlara girerek, biz ekip olarak bu işte şu kısma kadar sorumluyuz, kalanı diğer ekipte ve sonuç da bizi ilgilenmiyor bakış açısı sorun alanları oluşturabilmektedir. Bu noktalarda işi açan Product Owner’ın o işten beklediği çıktıyı ekibe iyi aktarması, kabul kriterlerini iyi belirlemesi, ekibin de başka ekiplerle çalışması gerekse bile işin sonucunu takip etmesi önemli bir kazanım olmaktadır. Diğer türlü her ekibin de “teknik olarak” sorumluluklarını yerine getirdiği ama müşteri bakış açısıyla beklenen çıktının üretilmediği durumlar oluşabilmektedir.

Bu noktada ekipler arası ortak mesaj gruplarının oluşturulması, Proje Yöneticisi ve Product Owner’ların günlük olarak aktif iletişim içerisinde olması, ortak yapılacak işlerde izlenecek yöntem ve sorumluluk paylaşımlarının yapılması ve çıktının birlikte kontrol edilmesi alınabilecek güzel aksiyonlar olarak gösterilebilir.

Delivery ekiplerinde olmayan uzmanlıklarla ilgili işler geldiğinde, önce SME desteği daha sonra ise banka tarafına bakan BT ekiplerinden belirli bir planlama dahilinde destek alabilmekteyiz. Alınan aktarımı kayıt altına alarak o işin de uzmanlığının Delivery tarafında oluşması için çalışmalar başlatılmakta, gerektiği durumlarda ilave kadrolar açılmaktadır.

Bağımlılık Yönetimi

Scrum, bir ekibi tanımlarken teorik olarak dışarıya olan bağımlılığı azaltan bir yaklaşımla, analist, yazılımcı, test mühendisi, ürün sahibi gibi rollerin hepsini bir yerde toplayarak bağımlılığı minimuma indirmeyi hedefler. Ürün takımları için bu çoğunlukla çalışırken, BOA gibi büyük bankacılık altyapısında çalışan proje takımları için etkin çalışmamaktadır. Bağımlılık yönetimi neredeyse her ekibin yönetmesi, efor sarfetmesi ve çözmesi gereken bir konu olmaktadır. Geliştirme ekiplerinin birbirlerine olan bağımlılıklarının yanı sıra altyapıya olan bağımlılıkların da yönetilmesi önemli başlıklar olmaktadır. Örneğin: Müşteri sayısının arttığı bir süreçte, çok sayıda müşterinin ortamlarının belirlenen sürelerde DevOps ekibi tarafından kurulması kritik öneme sahiptir. Diğer türlü ekiplerde bekleme istasyonları oluşabilmektedir. Burda neden ayrı bir DevOps ekibi kurulduğu sorusu gündeme gelebilir. Normal şartlarda beklenen, DevOps geliştiricilerin de ekiplere dağıtılması ve her ekibin kendi altyapı sorununu kimseye bağlı kalmadan çözmesi şeklinde olabilir. Ancak biz bu modeli belirli bir süre uyguladığımızda beklenen verim alınamamıştır. BOA kurulumu dediğimizde konu sadece ortam kurulumları olmamakta, altyapıya ve mimariye dokunan çok sayıda başlık ortaya çıkmaktadır. Bu başlıkları da her ekipte yer alacak birer ikişer mimari arkadaşın çözmesi verimli ve etkin olmamaktadır. Tecrübesi yüksek, etkin çalışan, kendisine olan bağımlılıkların farkında olan, takvimin gerisinde değil önünde olan, çalışma disiplinini oluşturmuş bir DevOps ekibi şirket için katalizör görevi görmekte ve yol açmaktadır.

Sprint devam ederken ortaya çıkan bağımlılıklar Impediment dediğimiz engel yönetimi ile takip edilmektedir. Retrolarda, çözülmeyen engellerle ilgili çözüm önerileri tartışılmakta ve alınması gereken aksiyonlar genelde Scrum Master üzerinden takip edilerek çözülmeye çalışılmaktadır.

Değişime Ayak Uydurma ve Sorun Çözme Kabiliyeti

Bir projeye başladığınızda her ne kadar takvim belli olsa ve yapılacaklar net olsa da işi yaparken çok sayıda farklı durumlarla ve sorunlarla karşılaşılmaktadır. Kendi içinizdeki durumları yönettiğiniz senaryoda bile müşteri tarafından gelebilecek yeni talepler, mevcut (as-is) yapının dışına çıkıldığı durumlar ortaya çıkabilmektedir. Çevik yönetim tecrübesi tam da bu durumlarda devreye girmekte, oluşan yeni duruma adaptasyon önem kazanmaktadır. Ayrıca aynı anda 3-4 müşterinin talepleriyle ilgilenme, her sprintte farklı müşteri taleplerine çözüm üretebilme Delivery ekiplerinde önemli bir kazanım olarak karşımıza çıkmaktadır. Ekiplerin uzmanlık alanları her ne kadar belirli modüllerle (domain) sınırlandırılsa da çoğu zaman çok farklı konularla ilgilenmek ve çözüm üretmek gerekmektedir. Bir bankanın 2-3 ekiple geliştirme yapıp destek verdiği bir konuda Delivery ekiplerinde 1-2 kişi ile bakılması gerebilmektedir. Bu konunun riskleri olduğu kadar konu üzerinde çalışan arkadaşlar için de farklı alanlara girme anlamında önemli fırsatlar sunmaktadır.

Dokümantasyon

Yapılan işlerin dokümante edilmesi, aynı işlerin başka müşteriler için özellikle de farklı kişiler tarafından yapılması durumunda çok önemli bir hale gelmektedir. Dokümantasyon, şirket içi bilgi donanım (know-how) sürekliliğinin, teknik ve iş bilgisi aktarımının önemli bir aracıdır. Şirkette işe başlayan tecrübeli veya tecrübesiz yeni birine sunabileceğiniz derli toplu bir doküman havuzunuz yoksa çok temel bir konuda eksikliğiniz var demektir. Yazılı çalışma kültürü, bireysel bir uğraştan ziyade şirket geneline yayılan organizasyonel bir çabayla daha anlamlı hale gelmektedir. Yazılım dünyasında dokümantasyon eksikliği kronik bir sorun olarak kabul edilir. Ancak bizim, şirket olarak Azure Wiki, her bir modülün kurulumuna özel hazırlanmış dokümanlar, kullanıcı kılavuzları, geliştiricilere rehber olacak Bilgin gibi doküman kaynaklarımız bulunmaktadır. Delivery ekiplerinde özellikle son yıllarda önemli bir doküman havuzu oluşturulmuş ve bu sayede bazı arkadaşlara sıfırdan yeni uzmanlıklar kazandırılmıştır. Faydasını gördüğün uygulamanın devamı senin ellerinde bakış açısıyla dokümantasyon oluşturma kültürü Delivery ekiplerinde devam ettirilmektedir.

Bir dokümanın kıymeti, hiç fikir sahibi olmadığın bir konu önüne geldiğinde geçmişte bu konuya kim bakmıştı, yazılan bir doküman var mı diye sorulduğunda daha iyi anlaşılmaktadır.