Yazılım geliştiricinin çevik olanı...

20 February 12, Monday @ 17:47

Çalıştığım şirkette epey bir süredir Agile (Çevik) yazılım geliştirme metotlarından biri olan Scrum (Ragbi oyununda takımın bir mesafeyi almak için kafa kol girişmesini ifade eden bir terim :) uygulanıyor.

Agile yaklaşımın temelinde gereklerin geliştirme süreci boyunca değişeceği, dolayısıyla yazılımın artımsal olarak kısa adımlarla geliştirilmesi, müşterilerin ve geliştiricilerin süreç boyunca etkileşimi, yazılımın her anında çalışabilir olması gibi bazı genel fikirler var. Scrum ise bu fikirlerden yola çıkıp geliştirme ve planlama sürecinin nasıl yürütüleceğini ayrıntılı olarak (ve süslü deyimlerle) tanımlayan bir yöntem.

Bu yöntemler hakkında detaylı bilgi internette bulunabilir, ben yalnızca deneyimlerimden yola çıkarak öznel görüşlerimi aktaracağım.

İlk olarak, Scrum geliştirme işinin teknik yönüyle ilgili çok az şey içeriyor. Kodlama standartları, sürüm kontrol, inşa, test, vb pratikleriniz olduğunu varsayıp devam edelim.

Scrum takımı, geliştiriciler, ürünün önceliklerini belirleyen bir product owner (ürün sorumlusu) ve Scrum süreçlerinin yürütülmesi, geliştiricileri bloklayan engellerin kaldırılması, varsa diğer takımlarla iletişim gibi işleri yapan ve belli aralıklarla değişebilen bir Scrum Master'dan (Scrum yöneticisi) oluşuyor.

Scrum süreci sabit sürelerle yapılan geliştirme hamleleri (sprint) şeklinde. Bu süre genelde birkaç hafta. Her sprint başında yapılacak işler planlanıyor ve sprint süresince bu planlama değiştirilmiyor. Tabii bu süre bazı işler için küçük bazıları için büyük. Scrum'ın buna çözümü, işleri kendi başına çalışan ve sorunun çözümünde bir miktar ilerlemeye karşılık gelen küçük adımlara bölmek ve her Sprint sonunda bir miktar çalışmayı ürüne katıp o adımı geçmiş olmak. Kağıt üzerinde mantıklı da gelse, uygulamada işler bu kadar basitçe adımlara ayrılamıyor elbette. Bazı durumlarda işi artımsal adımlara bölmek toplamda daha uzun zamanda bitmesine yol açabiliyor. Ara adımlarda çıkan ürünlerin kullanıcılara ulaşması da, bakım zorluğu yaratacaksa istenmeyen bir şey olabilir. Kimi zaman da sprint bitmeden bir özelliği yada hata düzeltmeyi ürüne katıp müşteriye sunmak isteyebilirsiniz. Dogmatik yaklaşmayıp bu tür durumlarda esnek davranabilirseniz sprint yönteminin genel olarak zararlı olmadığını düşünüyorum.

Her gün belirli bir saatte, ekipteki herkesin geçen gün ne yaptığını, bugün ne üzerinde çalışacağını ve devam etmesine engel olabilecek her türlü engeli anlattığı günlük toplantı (standup) yapılıyor. Bu toplantının ayakta ve aynı odada yapılması vb gibi bir dizi kural var ama siz şekilselliğe değil amaca bakın. Önemli olan kısa sürmesi, herkesin birkaç cümle söyleyip birbirinin yaptığından haberdar olması. Amaç ekibi onbeş dakkada senkronize edip, o gün başka toplantıların yapılmasına engel olmak! Scrum'ın pratikte en faydalı uygulaması bence bu.

Akla gelen her özellik ve geliştirme önerisi, user story (kullanıcı hikayesi) adı verilen ve genellikle "bir Gazeteci olarak kelime işlem programında sözcükleri sayabileceğim bir özellik istiyorum, böylece istenen uzunluğu aşmadan yazabileceğim" gibi birinci ağızdan yazılmış fonksiyonel iş tanımları olarak, backlog (yığılmış iş) adı verilen bir listeye ekleniyor. Sprint başında takım bu listeden o sprint süresince yapılacak işleri seçiyor. İşlerin fonksiyonel ve açık biçimde belirtilmesi (user story'ler işin tamamlanma koşullarını ve çeşitli testleri de içerebilir) faydalı bir yaklaşım, ancak backlog fikrini doğru bulmuyorum. Bu konuda Rework çok daha akıllıca bir yöntem öneriyor: Uzun listeler moral bozmaktan başka bir işe yaramaz. Eğer bir işi bir kenara yazmadığınızda unutuluyorsa zaten sandığınız kadar önemli ve yapılması gereken bir şey değildir. Müşteriler ile sürekli bir iletişiminiz varsa zaten size en öncelikli ve gerekli işi sürekli hatırlatacaklardır.

Burada bir sorun da, ürün kalitesini arttıracak ama müşteriye direk yansımayan ufak işleri sıraya almanın çok zor olması. Bunları ya kendi başınıza yapacaksınız, değerlendirmelerde gözükmeyecek ve bunlara harcadığınız zamanın hesabını veremeyeceksiniz. Ya da bunlara birer user story oluşturmak yada eldekilerden birine eklemek için hem zaman hem de ekibi ikna edip sıraya aldırmak için enerji harcayacaksınız.

Backlog'a atılan user story'ler takım tarafından zorluk ve tamamlanma sürelerine göre puanlanıyor. Bu puanlar o sprint'te başlanacak işleri belirlerken ve süreç boyunca burndown chart, velocity gibi süslü isimleri olmasına karşın aslında oldukça basit istatistikleri oluştururken kullanılıyor. Amaç takımın verimini ve işlerin yürüme hızını gözlemlemek ama burada detaylarına girmeyeceğim bir dizi kurnazca yöntemle yapılmalarına rağmen neredeyse hiç bir işe yaramıyorlar. Puanlama, eğer kendinizi kandırmıyorsanız, işe başlamadan bilemeyiz demekten ibaret. Diğer istatistikler ise elma ile armutu karşılaştırıyor.

Bu ölçme girişimleri ar-ge'yi teneke kutu üretimi sanan yöneticileri tatmin etmek için icat edilmiş olsa gerek. Onlara kötü bir haberim var, eğer projeyi en ufak detayına kadar kavrayabilecek kadar bilginiz yoksa bir ar-ge projesini yönetemezsiniz. İyi niyetliler sizi terkeder, kötü niyetliler metriklerinizi kandırır. Bu noktada maalesef velocity yıllar öncesinin kod satırı sayısı kavramından bir adım öteye geçebilmiş değil. Benim önerim şu: projeyi takip mi etmek istiyorsunuz, gidip commit eposta listesini okuyacaksınız. Anlamıyorum olup biteni diyorsanız da proje yönetmeyin lütfen!

Scrum kabaca böyle. Doğru uygularsanız faydalı olabilecek bazı pratikleri var. Bir bütün olarak almayıp, her pratik için bu doğru mu? ve benim durumuma uygun mu? diye sorgulamanızda fayda var. Şekilselliklerinden ve seremonilerinden ise kaçının derim, gülünç duruma düşmeyin.

Agile felsefesine daha uygun başka uygulamalar da mevcut. Bu yazının kapsamı dışındalar, o yüzden netten kendiniz araştırabilirsiniz. Ayrıca herhangi bir çelişki halinde Rework kuralları daima geçiş üstünlüğüne sahiptir :)

Post a comment