Agile Scrum Nedir? Nasıl Uygulanır?

Sizin evdeki hesap çarşıya uyuyor mu?

En azından yazılım dünyasında uymadığı aşikar. Değişime uyum sağlamadığımız ve zamana ayak uydurmadığımızda Porsche‘ye binmeyi hayal ederken kendinizi Şahin‘e binerken bulmadınız mı ?

Planlı olmak güzeldir ama uzun vadeli yapılan planlarda sapmalar olması kaçınılmazdır. Yazılım o kadar büyük bir dünya ki hayal bile edemediğimiz tüm ürünleri yazılım ile yapabiliriz. Madem elimizde böyle sihirli bir değnek var neden her şey yolunda gitmiyor?

Sene 1993, Jeff Sutherland (Scrum’ın kurucularından biri) Easel Corporation adındaki yazılım şirketinin eski ürünlerini altı aydan kısa bir sürede tamamen yenilemek için zorlu bir görevin altına girdi. O zamanlarda imkansız gibi gözüken bu işi daha az bütçe ve hata ile başardı. Daha sonra, uyguladığı yöntemleri detaylandırmak için meslektaşı Ken Schwaber ile birlikte çalışıp 1995'te ikisi ilk defa Scrum’ı (Scrum isminin rugby oyunundan esinlenildiği düşünülüyor) kamuoyuna sundu.

1995 yılından önce yazılımlar waterfall yaklaşımına göre planlanıyor ve ilerletiliyordu. Agile (Çevik) yaklaşımın ortaya çıkmasıyla yazılım yönetimine bakış açısı değişmeye başladı. Fazla hızlı değişen dünyada üretilen ürünlerin daha hızlı ve daha kaliteli olması insanları Agile yaklaşıma yöneltti.

Proje ilk başladığında onu anlamak ilerletmek kolaydır. Ama geliştirdiğin parçaları sırtında bir yük olarak taşımaya devam ettikçe projenin sonuna yani mutlu sona ulaşmak bir hayal olmaya başlar. Geliştirme ekibine getireceği yükün yanında işi isteyen tarafın da her şeyin yolunda gittiğini anlayamaması endişe vericidir.

Agile işi parçalara ayırıp hayata geçirerek bizi bir bilinmezlikten kurtarır. Yaptığımız işte yanlışlarımızı hızlı fark etmemizi sağlar ve zaman kaybetmemizi önler.

Bazen de planladığınız şey ortaya çıkardığınız üründen çok başkadır.

Proje sahibinin (Product Owner) istediği işin gerçekten kullanılabilir olduğunu ilk aşamadan anlaması önemlidir. Agile yaklaşım değişime açıktır. Teori ile pratiğin uyuşmaması gibi, her zaman projelerin doğru istekler (requirements) ile başlamadığı görülebilir. Yolda bazı değişiklikler olabilir. Projenin kapsamı değişebilir. Aslında yazılım denilen şey yaşayan bir süreçtir. Sizin bu süreci kurgulamanıza ihtiyacı vardır. Yazılımın bir sihirli değnek olduğunu söylemiştim. Yazılımı nasıl kullandığımız ile ortaya çıkan ürün doğru orantılıdır. Eğer doğru kullanırsanız beyaz atlı bir prens, yanlış kullanırsınız da elinizde bir kurbağa olması mümkündür. Agile size esneklik sağlar ama her zaman doğru yaklaşımı sunmaz. Her projenin ve ekibin uygun olduğu bir yöntem vardır. Önemli olan bunun belirlenmesidir.

Agile yaklaşımın bizim projemize uygun olduğuna karar verdik. Peki şimdi Scrum mı yoksa Kanban mı?

Metodolojimize karar verdikten sonra aslında Scrum ve Kanban bizim Agile ‘ı nasıl uygulayacağımız ile ilgilidir. Her yiğidin bir yoğurt yeme şekli vardır. Şirketin ve ekibin dinamiğini anlayıp proje bazlı bir yöntem seçilmesi en doğrusudur.

Peki biz bu seçimi nasıl yapmalıyız?

Scrum ‘da daha çok kural vardır ve disiplinlidir. Scrum daha stabil ve planlıdır. Kanban ’da kural çok daha azdır. Kanban değişime daha açıktır, daha hızlıdır.

Dediğim gibi Scrum biraz daha katıdır. Kuralları vardır ve bu kurallara bağımlılık her zaman teorideki gibi olmak zorunda değildir. Ekiplerin kendi bakış açılarını katması önemlidir.

Scrum olarak yürütülen işleri kabaca şu aşamalara ayırabiliriz.

• Backlog
• Estimation
• Prioritization
• Sprint Planing
• Sprint Review
• Retrospective

Backlog

Backlog ‘u yapacağınız işlerin ufak parçalara ayrılmış hali gibi düşünebilirsiniz. Yeni bir projeye başladınız ve 2–3 cümle ile size işi tarif ettiler. Sonra siz analiz yaptınız ve işin kapsamının çok büyük olduğunu gördünüz. Peki siz o işi parçalara ayırmazsanız geliştirme ekibi o işin içinde kaybolmaz mı? Bu sebeple ilk önce işi anlamlı en küçük parçalara bölüp iş listesi oluşturmamız gerekiyor.

Estimation

İş listemizi oluşturduktan sonra elimizde işlerin büyüklüklerini anlamamız gerekiyor. Bunun için işlerin karmaşıklık düzeyi, ne kadar zaman alacağı ve işin business değeri hesaba katılarak işin büyüklüğü belirlenir. Bu hesaplamayı geliştirme takımının hepsi beraber yapar.

Prioritization

Artık işlerin büyüklüğünü de biliyoruz. Bu işleri sprintlere belli bir sırada almamız gerekiyor. Yani katma değeri yüksek ya da aciliyeti olan işlerin bir sıralamasının yapılması ve geliştirmeye bu doğrultuda başlanması gerekiyor. İşin sahibi (Product Owner) ile bu öncelikler belirlenir.

Sprint Planing

Elimizde her şey mevcut ne duruyorsun sprint başlatsana. Sprint nedir önce onu açıklayalım. Belli bir süre içinde yapmayı düşündüğümüz işlerin hedeflerini tutturup canlı ortama alınabilir hale getirdiğimiz bir süreçtir. 2–4 hafta süreli sprintler planlanabilir. Proje tamamlanana kadar bir sprint bitiminde diğeri başlayacak şekilde planlama yaparak ilerlenir.

İşler hazır, büyüklükleri verildi ve önceliklendirmesi yapıldı. Artık geliştirme ekibinin önüne bu işi kodlaması için gönül rahatlığı ile bırakabilirsiniz. Artık biliyorsunuz işiniz emin ellerde.

Planlama geliştirme ekibi ile birlikte yapılır. Ekipteki kişilerin sayısı ve ne kadar iş çıkarttığı ile doğru orantılı bir şekilde sprint içerisine dahil edilecek işler belirlenir.

Sprint Review

2 hafta sonra… Sprintimiz bitti. Artık yaptığımız işleri değerlendirme vakti geldi. Bu süreçte geliştirme ekibi ve product owner beraber işleri inceler. Neler yapıldığı mümkünse demo şeklinde product ownera sunulur. Demo yapılamayacak teknik işler anlatılır. Hedefleri tutmayan, yetişmeyen işler varsa sebepleri ile belirtilir.

Retrospective

Hep beraber 2 hafta geçirdik ekip olarak. Ama nasıl geçirdik bir de bize sor…

İşte tam o noktada retrospective toplantıları içimizde problemi, sıkıntıyı ya da güzel devam eden şeyleri ortaya çıkarmak için yardımımıza koşuyor.

Bu toplantı sadece geliştirme ekibi ile yapılır. Bu toplantıda bir yönetici ya da product owner olmamalıdır. Ekip sorunlarını rahatça dile gelirmeli ki bir sonraki sprintte bunları yaşamamalıdır.

Dile getirilen sorunlara aksiyonlar planlanır. Sprint içerisinde bunlar yapılır ve bir sonraki toplantıda düzelme olup olmadığı ve yeni sorunlar olup olmadığı konuşulur.

Temel kavramların üzerinden geçerek Agile ve uygulanışı konuşunda biraz aklınızda bir şeyler oluşmasını umut ettim. Umarım istediğimi başarabilmişimdir.

Bu zamana kadar hep anlattım şimdi ilk defa yazıyorum. Yazmam gereken daha çok şey var diye düşünüyorum.

Zaman ayırıp okuduğunuz için teşekkürler.