Bir Bilgi Güvenliği Ekibinin Agile Yolculuğu
Giriş ve bu yazı kimlere hitap ediyor
Bilgi Güvenliği ekibi olarak, ne bir altyapı ekibi kadar günlük rutinde gelen işler ve önceden tahmin edilebilen tasklara, ne de bir yazılım geliştirme ekibi kadar proje esaslı çalışma yapısına sahip olduğumuzun farkındaydık. Öte yandan paydaşlarımızın değişen çalışma ortamı ve teknolojilerine bilgi güvenliği açısından hızlı adaptasyon sağlayabilmesi adına çevik bir cevap verme ihtiyacımız ise giderek artıyordu. Buradan yola çıkarak “ne yapabiliriz?” sorusuna kafa yorduk ve Agile metodolojisini kendi çalışma şartlarımız, gereksinimlerimiz açısından değerlendirerek, ekibimize uyarlama sürecimiz başlamış oldu.
Süreç boyunca bir agile koçundan destek almış olsak da, ekip olarak bizlerin bu alanda bir uzmanlığı olmadığı için terminoloji ve kavramlara ilişkin hatalarımız olabilir. Amacımız olabildiğince bizim gibi ekiplerin anlayabileceği, uygulayabileceği ve mümkünse dersler de çıkarabileceği bir yazı kaleme almak, bizim gibi çalışan veya bizim gibi kaygıları olan ekip veya takımlara yol göstermek.
Metodolojimize de uygun şekilde, bu yazıyı da ekip olarak hazırladığımız için, product owner, scrum master ve ekip üyelerinin ayrı ayrı yaklaşımlarını, kazanım ve duygularını görme fırsatı verdiğimizi düşündüğümüzden, organizasyon veya ekip yapısından bağımsız olarak benzer kaygıları duyan herkesin faydalanabileceğini umuyoruz.
Problem neydi?
Her Bilgi Güvenliği uzmanı bilir ki, bize gelen bütün işler acildir !?. Güvenlik değerlendirmeleri hemen yapılmalıdır, alınacak önlemler bir an önce alınmalıdır, denetimden gelen talepler her zaman önceliklidir ve üst yönetime her zaman hızlı geri dönüş verilmelidir. Bütün bu öncelik listesinin yanında ekip olarak bizim işleyişinde aksaklık görmüş olduğumuz konulara ilişkin proje planlarımız vardır ve çoğunlukla bunlara sıra gelmez ya da tüm işleri aynı anda yürütmeye çalışmak kaynaklı oldukça yavaş ilerler.
Bununla birlikte, uzaktan çalışma metodolojisinin kazanımları, aynı zamanda bir ekip olarak hareket etme konusunda da, hepimizin ilk kez karşılaştığı bazı zorlukları da beraberinde getirdi. Her ne kadar tüm iletişim imkanlarını sonuna kadar kullansak da, mutlaka bazı gecikmeler, senkronizasyon kayıpları veya ekip içi bilgi asimetrileri oluşabiliyordu. Bu da bizim gibi olabildiğinde herkesin temel prensip ve yaklaşımların bilincinde, içinde bulunduğu organizasyonda olup biten her şeyden, projelerden ve genel gidişattan haberdar olması gereken ekipler için bir risk teşkil ediyordu.
Son ve belki de en önemli sorunlarımızdan biri de kısa, orta ve uzun vadede takip etmemiz gereken işlerin raporlanabilir, ölçülebilir, önceliklendirilebilir, takip edilebilir ve açıkçası estetik bir çerçevede olmamasıydı. Şekil, çoğu zaman mesajın içeriğinin önüne geçtiği için, artık excel, notepad gibi araçlar gittikçe büyüyen ekibimize de yetmemeye başlamıştı. Planlama çok önemli olmakla birlikte, klasik anlamda bir yazılım geliştirme ekibi olmadığımız için hem içinde bulunduğumuz organizasyonun temel ilkeleri arasında yer alan, hem de global megatrend olan değişime ayak uydurabilme ve esnek olma yetkinliklerimizi de törpülemeyen, tam tersi keskinleştirebilecek, yapısal bir yaklaşıma ihtiyacımız vardı.
Stephen R. Covey’in iş dünyasında oldukça beğenilen kitabi “Etkili İnsanların 7 Alışkanlığı” kitabında yer alan zaman yönetimi matrisinde ise işler aşağıdaki tablodaki gibi bölünür ve Dr. Covey dikkati 3. karenin önemine çeker.
Tüm bu öncelikli işlerin arasında, ekip olarak kuruma ciddi katkı sağlayacak 3. Karedeki işler konusunda nasıl daha etkin olabiliriz sorusunun cevabını agile metodolojisi ile bulduk.
Çözüm önerisi ve nasıl başladık
Çözüm için kurumumuz proje yönetim ofisine danışarak, agile çalışma yöntemi konusunda bilgilendik ve tüm işlerimizi önümüze alıp, hep birlikte düşünmeye başladık. Rutin olarak yapmamız gereken kontrolleri, günlük operasyonları da bu kapsam içinde ele alarak metodolojide ilk önce “backlog” olarak anılan iş listemizi hazırladık. İşleri büyük parçadan küçük parçaya olacak şekilde sırasıyla; domainlere, domainleri epiclere, epicleri story’lere, storylerin altında ise tasklara böldük. (Taskları belilrleme aşamasına daha sonra da karar verilebilir). Tüm bu işleri parçalama sürecinde mümkün olduğunca basit düşünmeye çalıştık.
Her bir story’e, tamamlanması için gereken kaynak/işin zorluğu perspektifinden bakarak, Fibonacci,[1]sayı dizisinin baz alındığı “story point” puanları verdik ve hangi EPIC’in hangi ayda biteceğine yönelik büyük resmi görebileceğimiz bir roadmap oluşturduk.
Çalışma metodolojimizdeki bu değişikliğe başlarken belki de en zorlandığımız kısım roadmap’in ilk hazırlığıydı. Fakat hazırlarken fark ettik ki, işimizin en önemli parçası roadmap’in kendisiymiş. Roadmap hazırlığı tüm ekibin inputları önemli olmakla birlikte özünde product owner ve sponsorun sorumluluğu olduğundan bu paydaşlar için roadmap aslında stratejik liderliğin tam olarak uygulanabilir hale geldiği, somutlaşarak adeta ete kemiğe büründüğü bir çalışma olma özelliği taşıyor. Elbette roadmap, ilk kez hazırlandığı süreçte belki de ekibi en çok yoracak ve hatta bu dönüşümden vazgeçmeye teşvik edecek potansiyele sahip öğelerden biri. Özellikle bizim en temel kaygılarımızdan biri, roadmap’in ilk anda dört başı mamur şekilde hazırlanmasının imkansız olduğu, yapılacak hataların ve gözden kaçırılacak konuların ise ilerleyen dönemde tüm çalışmanın değerini yoksayacak kadar büyük olmasıydı. İkinci en büyük kaygımız ise roadmap’in baştan hazırlanmasının, uzun bir süre için (roadmap’in hazırlanacağı tarih aralığı) tüm esnekliğimizi kaybettireceği idi. Bu süreçte bir agile coach ile çalışmanın belki de en büyük faydalarından biri de bu kısımda oldu ve roadmap’in doğasının statik değil dinamik olduğu, yolda ilerlerken değişmesinin agile metodoljinin doğasında yer aldığı ve hataların her zaman telafi edilebileceğini bize aktararak tüm kaygılarımızı giderdi. Şimdiye kadar koştuğumuz 13 sprint süresince, hem product owner hem de sponsorun yönlendirmeleriyle neredeyse her sprint kısmen değişen roadmap’imize aynı zamanda 17 yeni epic gelmiş olması da bunun en iyi örneklerinden biridir muhtemelen.
Domain de dediğimiz bileşenler, bizim için aslında ekip olarak kuruma verdiğimiz hizmetler, yarattığımız katma değer merkezleri ve konuları olarak konumlandı. Şanslıydık ki daha önceden hazırlanmış mevcut bir servis envanterimiz vardı. Bu envanterde verdiğimiz hizmetler “ürün yönetimi — Xyz” kadar spesifik veya “uyum hizmetleri” kadar genel olabiliyordu. Eğer böyle bir servis envanterimiz olmasaydı da, yaptığımız veya yapacağımız tüm işleri konuları veya hizmet ettikleri ürün/araç/kar merkezi bazında ayrıştırıp belirli bir mantık çerçevesine oturacak kadar genel, fakat raporlandığı anda da çabucak anlaşılabilecek kadar spesifik yazmayı tercih ederdik.
Epic’lerimizi ise daha spesifik olarak, yapmayı planladığımız projeler, bileşenlerimizin alt kırılımı olarak konumlandırdık. Bir epic bizim için planlı bir proje, bir upgrade çalışması, bir revizyon, bir POC veya bir “politika iyileştirme insiyatifi” olabilir.
Metodolojinin uygulanmasında belki de en bize özgü kısım da ise; rutin olarak yaptığımız işleri roadmap’de birer epic konumlandırmadık, fakat onları da sprint planlarımıza aldık. Günlük, haftalık veya aylık olarak her periyotta yapılması zorunlu olan, operasyonel veya süreçsel konulara roadmap’de her ay için ayrı ayrı planlama göstermek yerine, roadmap’i yalnızca yapılacak yeni işler, yeni projeler, geliştirme ve planlı çalışmalara ayırdık. Bununla birlikte ekip eforunun tam olarak ölçülmesi adına, roadmap’e girmeyen tüm bu işler için hem epic bilgilerini oluşturduk, hem de her sprint planına mutlaka dahil ederek görünür olmasını sağladık.
Epic’lerimizin de alt kırılımında ise işlerin tamamen somutlaştığı, yapılması gereken işin fiili olarak tanımlandığı veya doğrudan bir çıktıyı tarif eden story veya product backlog item (PBI)’ların oluşturulmasına geldi. İlk planlama aşamasında, tüm tanımlı epic’lerimiz için PBI’ları oluşturabildik. Bu çalışmanın yine en zor ve zaman tüketen kısmı burasıydı çünkü üst seviyede belirlenmiş Epic’lerin altında, somut olarak hangi alt işler olabileceğini öngörmek başlı başına bir zorluk iken, bu işleri “bir sprintte bitebilecek” parçalara bölmek daha da zordu zira bu aşamada bir süre öngörüsü yapılması gerekiyordu. Her PBI/story’nin efor veya uzunluğunun “bir sprintte bitebilecek kadar” olma kuralı başta çok kafa karıştırıcı olsa da, sürecin devamında ne kadar faydalı olduğunu gördük. Story’leri belirleyip, backlog’umuzu oluştururken de içimizi rahatlatan en önemli nokta, backlog’un statik olmaması, her aşamada değişebileceği, güncellenebileceği, yeni maddelerin eklenip hatalı yapılan tanımlamaların çıkarılabileceği oldu. Aslında geriye dönüp baktığımızda, metodolojinin en faydalı yanının bu dinamizim olduğunu söyleyebiliriz.
Backlog da ilk olarak oluştuktan sonra, sprint adı verilen çalışma periyodumuzu, iki hafta olarak belirledik yani iki hafta boyunca bitirebileceğimiz işleri planımıza alarak ilerlemeye karar verdik.
Her ne kadar backlog’umuz hazır olsa da; bu süreçte en önemli nokta sprint planına alınması kararlaştırılan işleri mümkün olduğunca küçük parçalara bölebilmekti. Örneğin story’lere verdiğimiz puanların 21’i hiç aşmamasına karar verdik, eğer bir story 21’i aşıyorsa o konunun bir epic olduğunu değerlendirip, işleri yeniden hizalandırdık. Bu konuda “story point”lerin bir ekip dinamiği olduğunu da vurgulamak, 21 rakamının sembolik olduğunu anlamak gerekiyor. Her kişinin işlerin büyüklüğüne göre puan verme konusunda değerlendirmesi farklı olabilecektir, ancak bir iki sprint sonra ekip dayanışması sağlanarak ortak bir puanlama dilinin geliştiğini söyleyebiliriz.
Çalışma planı, roadmap hazırlandıktan sonra ise geriye kalan iş, bunları kurum CISO’suna (bizim için proje sponsoruna) sunup, onayını ve varsa roadmap konusundaki değerlendirmelerini almak oldu.
Son olarak metodoloji gereği olması gereken; toplantıların planlanması, rollerin belirlenmesi idi. Bunun için;
- Ekip içerisinde tüm bu süreci yönetecek, tıkanan durumları çözebilecek bir scrum master belirledik. Roadmap baz alınarak sprint planlarını belirleme işini yapacak product owner’ı ekip yöneticisi, sprint sonlarında yapılan işler, engeller ve gelinen nokta konusunda bilgilendireceğimiz sponsor rolünün ise CISO olması gerektiğine karar verildi.
- Her sabah bir önceki gün yapılan işleri, o gün yapılacak işleri ve varsa engelleri konuştuğumuz Dailyleri, Sprint başlangıç gününde hangi işlerin kapsama alınacağının belirlendiği sprint planlama toplantılarını, sprint sonunda sponsora yapılacak bilgilendirme sunumu için ise sprint review toplantılarını, sprint review sonrası ekipçe bir araya gelip memnun olduğumuz ve memnun olmadıklarımızı konuşacağımız Retro toplantılarını planladık ve artık yola çıkmaya hazırdık. Bu toplantıları ise sprint planına uygun şekilde iki haftada bir yapmaya başladık.
Rollerimiz
- Proje Sponsoru
Proje sponsoru, normal yazılım geliştirme projelerinde, projeyi bir anlamda finanse de eden, genellikle üst yönetimde görev yapan kişilerden oluşur. Bu metdoloji kapsamında da proje sponsoru, roadmap’e onay veren, roadmap’in genel hatlarıyla oluşturulmasını sağlayan, ekipten gelen girdileri de dikkate alarak, ekibin genel çerçevesini ve izleyeceği rotayı belirleyen kişidir. Bizim durumumuzda proje sponsoru bağlı olduğumuz direktörümüz (aynı zamanda kurum CISO) oldu ve kendisine iki haftada bir sprint review toplantılarında, hem sprint sonuçlarını hem de güncel roadmap’imizi aktardık.
- Product Owner
Bankamız içerisinde ve paydaşların en basit tabir ile işleri sahiplenen, hangi işin yapılacağını belirleyen ve önceliklendiren kişiye verilen görevdir. Bizim işleyişimiz gereği backlog konularımızın oluşturulmasında yer almakta ve neyin nasıl yapılacağı hakkında yönlendiren kişidir. Backlog’u sürekli güncel ve aktif tutması gerekmektedir. Product owner’ın en temel görevi, aslında backlog’un takibi ve backlog’daki işlerin tamamlandığına dair teyit ve onay vermesidir diyebiliriz.
- Scrum Master
Product owner’ın sahipliklerinin yanında scrum master takım içerisinde koordinasyonu sağlar. PO’nun yönlendirdiği işlerin en verimli şekilde ilerletilmesini sağlamak, takım arkadaşlarımızın karşılaştığı, sprint içerisindeki engellerin aşılmasında aktif rol oynamak gibi temel görevleri vardır. İhtiyaca göre bir sprint içerisinde örneğin refienment yapılıp yapılmaması gibi aksiyonların alınmasında takımın verimini arttıracak tüm aksiyonları almakla görevlidir. Aynı zamanda tüm ritüellere, takım tarafından aktif şekilde katılımın sağlanmasını temin etmelidir. Bu görevleri yerine getirirken genel bir guide olan Scrum Guide’ı çok iyi bilmesi ve uygulaması gerekmektedir.
Kullandığımız araçlar
Tüm bu süreci excel üzerinden yönetmeyi başlangıçta denedik ve oldukça yorucu olduğunu deneyimledik. Bunun üzerine kurumda hali hazırda kullanılan jira ortamına geçiş sağlayarak, tüm backlogumuzu bu araca yansıttık. Böylece aktif sprintteki işler, aktif sprintteki işlerin durumunu gösteren (to do, continue, done) task statü tablosu ve bekleyen işleri kolaylıkla yönetebildiğimiz bir ortama sahip olduk. Jira, backlogun takip edilmesi, bileşen-epic-story gibi bağlantıların kolayca oluşturulabilmesi, ve kullanıcı dostu bir dijital board oluşturması gibi özellikleri ile hem estetik hem de kullanışlı bir altyapı sağlamış oldu. Ayrıca üzerinde yapılan tüm değişiklikleri ve hareketleri kayıt altına alabildiği için rahatça takip edilebilir ve raporlanabilir bir arayüz sundu.
Jira dışında, özellikle retro toplantılarımızda kullandığımız easyretro da, bu ritüelin gerektirdiği anonimliği sağlaması ve aksiyon planlarının takip edilmesi gibi özellikleri ile çok yardımcı oldu.
Yolda neler öğrendik?
Yol boyunca, çalışma yönetimimizi geliştirebileceğimiz bazı konuları keşfettik;
- Bazı işlerin yetişmemesindeki nedenin o işe ilişkin önhazırlığın yapılması gerekliliği olduğunu anladık. Bunun için sprintin 2. Haftasına “Refinement” toplantılarını planlayarak, bu toplantıda bir sonraki sprintte ele alınacak işleri konuşmayı ve önbilgi alma gereksinimini değerlendirmeyi hedefledik.
- İşlerin hedeflediğimiz sürelerde bitmemesinin bir sebebinin, bazı işlerimizin ekip olarak bizim tekelimizde ilerlememesi farklı ekiplerin de katkısının gerektiğini ve süre konusunda kontak kişilerle mutabık kalarak ilerlemenin önemini anladık.
- Bir sprintte tamamlanmayan task’ların, doğrudan yeni sprinte alınırken story point’lerinin mutlaka tekrar değerlendirilmesi gerektiği ve yeni işlerle birlikte doğru planlanması gerektiğini öğrendik.
- Her sprintte “Plansız İşler, Prod Hataları” şeklinde bir story açmamız gerektiği ve daha planlama aşamasında buna belirli bir kaynak ayırmamız gerektiğini, böylece meydana gelmesi olası konulara müdahalelerin tüketeceği eforun diğer işlere etkisini azaltacağını farkettik.
- Sprintin ikinci haftası Salı günü mevcut görevler içinde bir risk değerlendirmesi yapıp, tamamlanması riskli olan konular varsa bunlarla ilgili erken aksiyon alma, ekip içinde destek vermek gibi çözümleri hayata gecirmeye çalıştık.
Şimdi neler yapıyoruz?
Bugün geldiğimiz noktada, backlog’a sonradan eklenen işleri planlayabiliyor, işlerimizin büyüklüğünü ölçebiliyor, Stephen R. Covey’in vurguladığı acil değil ama önemli işlere vakit ayırabiliyoruz. En önemlisi ise hangi işe ne kadar zaman ayırdığımızı, rutin olarak karşılaştığımız engellerimizi, sponsorun beklentilerini ne oranda karşılayabildiğimizin resmini görebiliyor, ekip içi dayanışmayı arttırdığımıza ve kuruma sağladığımız katkıyı günden güne arttırdığımıza inanıyoruz.
En memnun olduğumuz ritüel daily, fakat en az memnun olduğumuz ise retro. Gerçi product owner’ımız en çok retro’ları sevdiğini ekseriyetle beyan etmekte fakat ekibin geri kalanı için aynı şeyi söyleyemiyoruz. Refinement toplantılarımızı da takvimde tutmakla birlikte ihtiyaç durumunda yapıp, bir ön-planlama toplantısı şeklinde konumlandırıyoruz.
İleride neler yapacağız?
Özellikle product owner ve sponsorumuzun şu anda bu metodolojiden en büyük beklentisi, geride kalan 13 sprint’te de özellikle Jira üzerinde yarattığımız verileri analiz ederek, hangi Epic veya hangi bileşen daha çok efor aldı, story point’lerimiz (dolayısıyla efor ve zamanımız) daha ziyade hangi çalışmalara harcandı, bu çalışmaların hangileri daha çok katma değerli gibi sorulara yanıt bularak, süreçlerimizi iyileştirmek ve gelişim noktalarını tespit etmek. Zaten, bu metodolojinin en büyük katkılarından biri de, kısa vadeli planlamalar ve sürekli kendini gözden geçirerek düzeltmeye yönelik yaklaşımla uzun vadeli hedeflerde başarıya yaklaştırması diye düşünüyoruz.
Sizlere de ilham olması dileğiyle…
[1] Fibonacci dizisi; her sayının kendinden önceki ile toplanması sonucu oluşan bir sayı dizisidir. 1, 2, 3, 5, 8, 13, 21, 34, 55, 89…
