Bir yolculuğa çıkılmadan önce gerekli hazırlıklar yapılır. Bu hazırlıklar yolculuğa çıkabilmek için atılması gereken zorunlu adımlardır. Bu adımlar atılmadığı taktirde, yolculuğun başarısız olması, yolculuğun iptali ya da planlanan zamanda tamamlanamama rizikosu doğabilir.
Yolculuğa çıkıldıktan sonra nihai amaç varış noktasına planlanan zamanda erişmektir. Varış noktasına planlanan zaman diliminde erişildiğinde, yolculuk tamamlanmış olarak kabul edilir.
Bir yolculuğun başlaması ve bitişi hakkında özetle şunları söyleyebiliriz:
- Yolculuğa çıkabilmek için bazı koşulların yerine gelmesi gerekmektedir. Bu koşullara başlama kriterleri ismini verebiliriz.
- Yolculuğu tamamlanmış olarak kabul edebilmek için bazı koşulların yerine gelmesi gerekmektedir. Bu koşullara bitirme kriterleri ismini verebiliriz.
Bir yolculuk için tanımladığımız başlama ve bitirme kriterlerini yazılıma aktarabiliriz. Yazılımda yolculuk bir kullanıcı senaryosunu koda dökmekle başlar. Bu senaryo kodlandığında yolculuk tamamlanmış olur. Ama ne zaman bir kullanıcı senaryosunun kodlanmak için hazır olduğunu anlayabiliriz? Yani ne zaman yola çıkmak için hazırız? Aynı soruları kullanıcı senaryosunu tamamladığımızda da sorabiliriz: Ne zaman bir kullanıcı senaryosunu gerektiği şekilde koda döktüğümüzden emin olabiliriz? Yani ne zaman yolculuğumuzu tamamladık?
Çevik süreçlerde yolculuğa çıkabilmek ve yolculuğun tamamlandı olarak görülebilmesini sağlamak için başlama ve bitirme kriter tanımlamaları kullanılır. Yolculuğa çıkabilmek için kullanılan kriter tanımlamasına Definition Of Ready (DOR), yani hazır kriterleri tanımlaması, yolculuğu tamamlandı olarak adlandırmak için Definition Of Done (DOD), yani tamamlandı kriterleri tanımlaması oluşturulur. Şimdi DOR un ve DOD un ne olduklarını ve ne amaçla kullanıldıklarını yakından inceleyelim.
Hazır Kriterlerinin Tanımlanması (DOR)
Müşterimiz aşağıda yer alan kullanıcı senaryosunun tarafımızdan implemente edilmesini istemektedir:
[source language=”java”]
"Kullanıcı e-posta adresini ve şifresini kullanarak, login işlemini gerçekleştirir."
[/source]
Hangi şartlar altında bu kullanıcı senaryosunu koda dökmeye başlayabiliriz? Bu yolculuğa çıkabilmek için ihtiyaç duyduğumuz her şeye sahip miyiz? Her şeye sahip olduğumuzu nasıl kontrol edebiliriz?
Yazılım deterministik sonuçlar doğurmakla yükümlüdür. Bunlar müşterinin uygulamadan olan beklentileridir. Bu yüzden bir kullanıcı senaryosunun yazılımcı olarak sorumluluğunu üstlenerek, yola çıkmadan önce objektif bir şekilde yolculuğa hazır olup, olmadığımızı kestirebilmemiz gerekmektedir. Subjektif algılara dayalı bir analiz, yolculuğumuzun başarısız sonuç vermesine sebep olabilir. Sonuç itibari ile bir yerden başka bir yere giderken, kendimizi körü, körüne yola vermiyor ve yolculuğa çıkabilmek için gerekli şartları göz önünde bulunduruyoruz. Aynı şey bir kullanıcı senaryosu için yola çıkarken de geçerlidir.
DOR bir listedir ve kullanıcı senaryolarının implementasyon için hazır kriterlerini ihtiva eder. Bir kullanıcı senaryosu sadece DOR uyumlu ise, implemente edilebilir konumundadır. DOR uyumlu olan bir kullanıcı senaryosu yolculuk için tüm şartların yerine geldiği ve yolculuğun başlayabileceği anlamına gelmektedir.
DOR uygulama bünyesinde yer alacak tüm kullanıcı senaryoları için geçerli bir tanımlamadır ve şu kriterleri ihtiva edebilir:
- Kullanıcı senaryosunun öncelik sırası ve önemliliği müşteri tarafından tanımlandı.
- Müşteri kullanıcı hikayesi hakkında detaylı bilgiyi ekip ile paylaştı.
- Kullanıcı senaryosu için gerekli implementasyon süresi tüm ekip tarafından tahmin edildi.
- Müşteri tarafından onay/kabul (acceptance) kriterleri tanımlandı.
Şimdi tekrar üzerinde çalıştığımız kullanıcı senaryosunu hatırlayalım:
[source language=”java”]
"Kullanıcı e-posta adresini ve şifresini kullanarak, login işlemini gerçekleştirir."
[/source]
Bu kullanıcı senaryosunu alıp, yola çıkabilmek için DOR listesinde yer alan kriterlerin yerine gelmiş olması gerekir. Öncelikle müşterinin bu kullanıcı senaryosuna ihtiyacı olduğundan emin olmamız gerekmektedir. Müşteri için ilk etapta önemli olmayan kullanıcı senaryolarının implemente edilmeleri, zaman ve kaynak kaybıdır. Zaman içinde müşteri gereksinimleri değişebileceğinden, hangi öneme sahip olduğunu bilmediğimiz bir kullanıcı senaryosu üzerinde çalışmanın nasıl bir netice doğuracağı malum. Bu yüzden DOR kriterlerinden ilki, müşteri tarafından kullanıcı senaryosuna öncelik sırası verilmesi gerektiğini söylemektedir. Müşteri oluşturduğu kullanıcı senaryoları için öncelik sırası vermekle yükümlüdür. Değişik planlama toplantılarında müşteri bu bilgiyi programcılarla paylaşır. Bu şekilde programcılar kullanıcı senaryolarının hangi önceliğe göre implemente etmeleri gerektiğini bilirler.
Müşteri tarafından oluşturulan kullanıcı senaryosu bir cümleden oluşmaktadır. Müşterinin ne istediğinin tam olarak anlaşılabilmesi için müşterinin ne istediğini ekiple paylaşması gerekir. Eğer ekip içinde kullanıcı senaryosu hakkında yeterinde bilgi mevcut değilse, kullanıcı senaryosu hazır kriterlerinden birisini ihlal ettiğinden dolayı implemente edilemez. Müşteri kullanıcı senaryoları hakkında detaylı bilgiyi ekip ile paylaşmakla yükümlüdür.
Diğer bir hazır kriteri, kullanıcı senaryosu için gerekli implementasyon süresinin tahmin edilmiş olmasıdır. Süre tahmini planlama toplantılarında ekip tarafından yapılır. Bu özelliğe sahip olmayan kullanıcı senaryoları implementasyon için hazır değildir. İterasyon bazlı çalışan ekipler, iterasyon sonunda müşteri için kullanılabilir bir uygulama sürümü oluşturmakla yükümlüdür. İterasyonlar belli bir zaman dilimini kapsar. İmplementasyon süresi tanımlı olmayan bir kullanıcı senaryosu, iterasyon gidişatını olumsuz etkileyebilir. En kötü ihtimalle kullanıcı senaryosu tamamlanamadığı için sürüm oluşturulamaz.
Onay/kabul kriterleri müşteri tarafından tanımlanan ve müşteri ve programcı arasında yapılacak iş hakkında detayları ihtiva eden bir sözleşmedir. Bu yazımda onay/kabul kriterlerinin nasıl olmaları gerektiği konusuna değindim. Onay/kabul kriterleri müşterinin uygulamadan olan beklentilerini ifade ederler. Her kullanıcı senaryosunun tanımlı onay/kabul kriter listesi olmalıdır. Aksi taktirde müşterinin ne istediğinden emin olmamız mümkün olmayabilir. Programcı olarak onay/kabul kriterlerinden yola çıkarak, onay/kabul testleri oluşturabiliriz. Tanımlı olan tüm onay/kabul kriterlerini yansıtan ve çalışır durumdaki onay/kabul testleri, programcı olarak müşterinin beklentilerini tatmin eden bir kullanıcı senaryosu implementasyonu yaptığımız anlamına gelir. Onay/kabul kriterleri tanımlı olmayan bir kullanıcı senaryosu üzerinde çalışmak, senaryoyu tamamladığımızı düşünsek bile, müşterinin “istediğim şey bu değildi” söylemiyle karşı karşıya kalma rizikosunu artırır. Oysaki müşteri tarafından tanımlanmış olan onay/kabul kriterleri doğrultusunda yaptığımız çalışma, müşterinin yaptığımız çalışmaya itiraz etme ihtimalini düşürür, çünkü oluşturduğumuz ve çalışır durumda olan onay/kabul testleri kendisi tarafından tanımlanan onay/kabul kriterlerini baz almaktadır. Bu “programcı olarak müşteri ne istiyorsa, onu implemente ettim” anlamına gelmektedir.
DOR genel anlamda müşteri ile ekip arasında iş başlangıcını tanımlayan bir sözleşme metnidir. Bu sözleşmede yer alan kriterler yerine gelmediği sürece, programcı olarak kullanıcı senaryoları için sorumluluk altına girmeme hakkımız bulunuyor. Eğer DOR olmadan işe başlıyorsak, hem programcı olarak biz tutamayacağımız bir söz vermiş olmaktayız, hem de müşteri gereksinimlerini anlaşılır bir şekilde ifade etme zahmetine katlanmamıştır.
Birçok projenin en zorlandığı alanlardan birisi, yapılan planlamaya uygun bir şekilde sürümlerin oluşturulamamasıdır. Bunun başlıca sebeplerinden birisi DOR un eksikliğidir. DOR un eksikliği sürüm planlamasını zora sokar ve ekip içindeki programcıların deterministik netice oluşturmalarını engeller. Sürüm planında yer alan her kullanıcı senaryosunun (user story) DOR uyumlu olması demek, test edilebilir, açık ve net anlaşılır ve ölçülebilir yapıda olması demektir.
Bitirme Kriterlerinin Tanımlanması (DOD)
DOR yola ne zaman çıkabileceğimizi söyleyen doküman ise, DOD hedefe ne zaman vardığımızı anlamamızı sağlayan dokumandır. DOD projenin sağlıklı ilerlemesi için DOR kadar önemlidir. DOD bünyesinde bir kullanıcı senaryosunun tamamlanış kriterleri yer alır. Örnek bir DOD şu şekilde tanımlanabilir:
- Müşteri tarafından tanımlanan onay/kabul kriterleri için onay/kabul testleri oluşturuldu ve hepsi çalışır durumda.
- Kod hatasız derleniyor ve tüm testler çalışır durumda.
- Ekip içinden bir programcı ile kod inceleme (code review) seansı yapıldı. Bunun yanı sıra Sonar gibi araclar yardımı ile kodun statik analizi ve gerekli düzeltmeler yapıldı.
- Gerekli dokümentasyon oluşturuldu.
- Kullanıcı senaryosunu ihtiva eden kod versiyon kontrol sunucusuna eklendi.
- Kullanıcı senaryosunu ihtiva eden kod sürekli entegrasyon sunucusu (Jenkins) tarafından uygulamanın diğer bölümleri ile entegre edildi. Tüm testler çalışır durumda.
Çalıştığım bir projede kullanıcı senaryolarını mümkün olan en iyi standartlarda implemente ettiğime dair imza atmam istenmişti. İmza atmam, ama isterseniz yemin edeyim demiştim 🙂 Şaka bir yana bunun gibi durumlar DOD eksikliği ve programcıya olan güvensizliğin ibareleridir. DOD oluşturulduğu taktirde, programcı yolculuğunu tamamlamak için hangi adımları atması gerektiğini bilir ve çalışmalarını bu yönde sürdürür. DOD yolculuğun nerede son bulması gerektiğinin habercisidir.
DOD bünyesinde olması gereken en önemli kriter, onay/kabul kriterlerinin yerine getirildiğinin ispatını teşkil eden onay/kabul testlerinin varlığının mecburiyetidir. Aksi taktirde kullanıcı senaryosundan sorumlu olan programcı müşteri tarafından ifade edilen gereksinimleri tatmin eden kodu yazdığından emin olamaz. Bu durumda programcı müşterinin her türlü itirazına maruz kalabilir. Bunun önüne geçmenin ve müşterinin ifade ettiği gereksinimleri tatmin eden kodu oluşturmanın en sağlıklı yöntemi, onay/kabul kriterlerini baz alan onay/kabul testleri oluşturmaktır. Onay/kabul testleri olmayan bir kullanıcı senaryosunun tamamlandı olarak görülmesi imkansızdır.
Diğer önemli bir DOD kriteri de, kullanıcı senaryosunu geliştiren programcının yaptığı çalışmaları bir ekip arkadaşıyla paylaşmasıdır. Bu eşli programlama (pair programming) yöntemi ya da implementasyon sonunda kod inceleme seansı (code review) bünyesinde gerçekleşebilir. Bu şekilde programcının oluşturduğu çözüm ekip içinde paylaşılır ve varsa mevcut hataların giderilmesini sağlanır.
DOD un eksikliği müşteri gereksinimlerini tatmin etmeyen ve hata ihtiva eden kod birimlerinin oluşmasını hızlandırır.
DOR ve DOD statik dokümanlar değildirler. Zaman içinde ekibin ihtiyaçları doğrultusunda değişikliğe uğrayabilirler. Onay/kabul kriterlerinin programcılar tarafından tanımlandığı projeler de gördüm, müşteriler tarafından tanımlandığı projeler de. Gün sonunda kimin, neyi tanımladığı değil, çalışır ve müşteri gereksinimlerini tatmin eden bir uygulamanın oluşması önemlidir. DOR ve DOD da bu amaca hizmet eden araçlardır. Bu şekilde algılanmaları ve uygulanmaları projelerin gidişatlarını olumlu yönde etkilemektedir.
Özcan Acar
EOF (End Of Fun)