30 saniyelik özet

Definition of Ready, kısaca DoR, bir iş maddesine başlayabilmek için gereken hazırlık hakkında takımın oluşturduğu ortak anlaşmadır. Türkçede hazır olma tanımı olarak ifade edilebilir. Kullanıcı ihtiyacının anlaşılması, önemli bağımlılıkların görünür olması ve beklenen davranışın konuşulması gibi konuları hatırlatabilir. Scrum’ın zorunlu bir unsuru değildir. “Hazır” olmak, bütün soruların cevaplandığı anlamına gelmez. Ekip hangi bilgiyle başlayabileceğini, hangi belirsizliğin çalışmayı engellediğini ve hangisini çalışırken ele alabileceğini değerlendirmelidir. DoR’un yararı, kontrol listesinin tamamlanmasından çok başlangıç kararının kalitesinde aranmalıdır.

Neden önemli?

Bir iş maddesinde “Raporu dışa aktarma özelliği geliştirilecek” yazıyor. Tasarım bağlantısı ve tahmin eklenmiş, sorumlu atanmış. Buna rağmen raporun kimler tarafından indirileceği, hangi verilerin dosyaya gireceği ve erişim yetkilerinin nasıl korunacağı belli değil. Kayıt dolu görünse de ekip aynı işi anlamıyor olabilir.

Geliştirme başladıktan sonra bu soruların ortaya çıkması, kapsamı ve çözüm seçeneklerini değiştirebilir. Yetki modeli başka bir ekibe bağlıysa bekleme yaşanabilir. Kullanıcının istediği dosya biçimi mevcut çözümden farklıysa yeniden çalışma gerekebilir. Başlangıç öncesindeki kısa bir konuşma, bu kararların zamanında alınmasını sağlayabilir.

DoR, tekrar eden hazırlık eksiklerini ortak bir değerlendirmeye dönüştürmek için kullanılabilir. Örneğin ekip sürekli gerçekçi test verisi bulamadığı için duruyorsa, uygun verinin nasıl sağlanacağını önceden konuşmayı anlaşmasına ekleyebilir. Böylece geçmişteki aksaklıktan somut bir çalışma değişikliği çıkarır.

Yönetici açısından mesele, işlerin hangi koşullarda başlatıldığıdır. Hazırlığı eksik işe başlamak bazı durumlarda makul olabilir; fakat bu kararın riski ve gerekçesi açık olmalıdır. “Hazır” etiketi, kimsenin sorgulamadığı bir güvenceye dönüştüğünde belirsizliği gizler.

Diğer taraftan hazırlık beklentisi gereksiz büyüyebilir. Küçük bir metin düzeltmesine kapsamlı tasarım belgesi istemek, karar için yeni bilgi üretmeden bekleme yaratır. Kullanılan koşulun hangi sorunu önlediği açıklanabilmelidir. Gerekçesi kalmayan koşullar, sırf geçmişte listeye eklendi diye korunmamalıdır.

Terim nedir?

Scrum, karmaşık ürün çalışmalarını yönetmeye yardımcı olan bir çerçevedir. Scrum Alliance’ın DoR rehberi, hazır olma tanımının bu çerçevenin parçası olmadığını ve takımların isterse kullanabileceğini açıklıyor. Rehber, koşulların katı kurallar yerine ortak anlayışı destekleyen yönlendirmeler olarak ele alınmasını öneriyor.

Product Backlog, ürünün geliştirilmesi için gereken işlerin sıralı listesidir. DoR, listedeki bir maddenin çalışmaya ne kadar uygun olduğunu konuşmaya yardımcı olabilir. Hazırlığı yalnızca Product Owner’ın, yani ürün sahibinin tamamlayıp geliştiricilere teslim edeceği ayrı bir aşama gibi düşünmek yanıltıcıdır. İşi yapacak kişilerin katkısı da gerekir.

Yöntem kaynağı: Scrum Alliance, Pros and Cons of a Definition of Ready.

Definition of Done, yani tamamlanmış sayılma tanımı, ortaya çıkan ürün çalışmasının karşılaması gereken kalite koşullarını ifade eder. DoR başlangıç hazırlığını, DoD ise tamamlanma durumunu değerlendirir. Bir maddenin başlamaya uygun bulunması, sonucun kaliteli veya kullanılabilir olduğunu kanıtlamaz.

Acceptance Criteria, yani kabul kriterleri, belirli bir işten beklenen davranışı açıklayan koşullardır. DoR içinde bu koşulların yeterince anlaşılır olması istenebilir. Ancak “Kabul kriterleri yazıldı” ifadesiyle kriterlerin gerçekten anlaşıldığı aynı şey değildir. Kullanıcıya etkisi olan örnekler üzerinden konuşmak, yalnızca alanın dolu olup olmadığını kontrol etmekten daha yararlı olabilir.

Başlangıç kararı ayrıca işin türüne bağlıdır. Yeni bir özellikte araştırma ve tasarım bilgisi önemli olabilirken, üretimdeki bir hatada sorunun yeniden oluşturulması ve etki alanının bilinmesi öne çıkabilir. Her maddeyi aynı belge kümesine zorlamak yerine hangi hazırlığın o karar için gerekli olduğu tartışılmalıdır.

Gerçek vaka: DWP’de erişilebilirliği başlangıçta konuşmak

Birleşik Krallık Department for Work and Pensions, yani Çalışma ve Emeklilik Bakanlığı, erişilebilirlik rehberinin çevik takımlar bölümünde DoR için somut koşullar yayımlıyor. Erişilebilirlik, farklı yetenek ve ihtiyaçlara sahip kişilerin hizmeti kullanabilmesini destekleyen tasarım ve geliştirme yaklaşımıdır.

Rehber, kullanıcı hikâyeleri hazırlanırken tasarımın nasıl erişilebilir hale getirileceğinin takım tarafından konuşulmasını istiyor. Sayfa başlıkları ve adresleri gibi önemli içeriğin de iş kaydında bulunmasını öneriyor. Örnek koşullar arasında hata mesajlarının içerik tasarımcısıyla kararlaştırılması, içeriğin ve tasarımın takımca incelenmesi yer alıyor.

Belge ayrıca, erişilebilirlik doğrulamasını tamamlanma koşulları içinde de ele alıyor. Bu ayrım önemli: Başlangıçta tasarımın konuşulması, geliştirilen hizmetin test edilmesinin yerine geçmiyor.

Bu, kurumun yayımladığı çalışma rehberine dayanan belgelenmiş bir uygulamadır. Kaynak, koşulların bütün ekiplerde nasıl uygulandığını veya teslimat üzerindeki sayısal etkisini göstermiyor. Vakadan çıkarılabilecek ders, önemli bir kalite konusunun hazırlık aşamasında görünür tutulmasıdır; sonuç üzerindeki etkisi ayrıca değerlendirilmelidir.

Kaynak: DWP Accessibility Manual, Agile teams, Definition of ready ve Definition of done bölümleri.

Varsayımsal örnek: Kurumsal raporu dışa aktarmak

Bir kurumsal yazılım ekibinde dışa aktarma talepleri geliştirilmeye başlandıktan sonra sık sık değişiyor. Ekip, geçmiş işleri inceleyince kullanıcı rolü, veri kapsamı ve yetki koşullarının başlangıçta yeterince konuşulmadığını görüyor.

Ürün sahibi ve geliştiriciler, yeni talep için önce kullanıcının amacını açıklıyor: Bölge yöneticisi, sorumlu olduğu satışların özetini kurum içindeki değerlendirme toplantısına taşımak istiyor. İş analisti örnek raporu topluyor. Tasarımcı, dosya hazırlanırken kullanıcının hangi durumu göreceğini gündeme getiriyor.

Ekip DoR anlaşmasını bu ihtiyaca uyguluyor. Hedef kullanıcı ve kullanım amacı anlaşılmış mı? İndirilebilecek veri sınırı belirlenmiş mi? Yetki kontrolü için gerekli bilgi var mı? Dosya biçimi konusunda karar verilmiş mi? Veri içermeyen raporun davranışı konuşulmuş mu?

Yetki hizmetinin başka ekip tarafından yönetildiği anlaşılıyor. Gerekli erişim bilgisi henüz yok. İşin tamamını hazır diye işaretlemek yerine bağımlılığın sahibi ve çözüm zamanı kaydediliyor. Geliştiriciler, eldeki bilgiyle yapılabilecek hazırlığı ve erişim gelmeden doğrulanamayacak davranışı ayırıyor.

Bu sırada küçük bir hata düzeltmesi gündeme geliyor. Yeni özellik için gereken rapor örneğinin bu düzeltme için anlamlı olmadığı görülüyor. Ekip, aynı listeyi mekanik biçimde uygulamıyor; hatanın etkisini, yeniden oluşturulmasını ve gerekli doğrulamayı konuşuyor.

Çalışma sonrasında, DoR’un hangi sürprizleri erken ortaya çıkardığı ve hangi gereksiz beklemelere neden olduğu inceleniyor. Listeye yeni madde eklemek otomatik çözüm sayılmıyor. Sorun bir bilginin hiç konuşulmamasıysa koşul değişebilir; bilgi konuşulup paylaşılmadıysa kayıt ve iletişim biçimi iyileştirilebilir.

Yaygın üç hata

  1. Hazırlığı belge tamamlama yarışına çevirmek

Dolu alanlar ortak anlayışı garanti etmez. Her koşulun hangi kararı desteklediğini açıklayın. Ekip üyeleri aynı maddeyi farklı anlatıyorsa belgeyi tamamlanmış saymadan bu farkı konuşun.

  1. Bütün belirsizliklerin giderilmesini beklemek

Bazı sorular ancak uygulama veya kullanıcı denemesi sırasında cevaplanabilir. Başlamayı engelleyen bilinmeyenlerle çalışırken öğrenilebilecek konuları ayırın. Çözülemeyen sorular için sorumlu ve değerlendirme zamanı belirleyin.

  1. DoR’u sorumluluğu devretme aracı yapmak

“Ürün sahibi hazır getirmedi” demek, teknik bilgi ihtiyacını çözmez. Hazırlığa gerekli uzmanlıkları dahil edin. DoR, tarafların birbirine iş reddettiği bir mekanizma haline gelirse hangi konuşmanın eksik kaldığını inceleyin.

Mini uygulama / şablon

Yaklaşan bir iş maddesi için aşağıdaki alanları birlikte değerlendirin.

İşin türü ve kullanıcı ihtiyacı
—
Beklenen sonuç
—
Başlamak için gerekli bilgi
—
Önemli kabul kriterleri
—
Veri, güvenlik ve erişilebilirlik etkileri
—
Bağımlılıklar ve sorumluları
—
Çalışmayı engelleyen bilinmeyenler
—
Çalışma sırasında ele alınabilecek sorular
—
Başlangıç kararının gerekçesi
—
Koşulların yararını gözden geçirme zamanı
—

Her hazırlık koşulunun yanına önlemek istediği sorunu yazın. Ardından tamamlanmış işleri inceleyerek koşulun gerçekten kararları destekleyip desteklemediğini değerlendirin. Hazırlık konuşması tekrar eden sürprizleri azaltıyor mu, yoksa yalnızca işleri bekletiyor mu? Cevaplara göre anlaşmayı sadeleştirin veya düzeltin. DoR’un kendisi de takımın öğrendikleriyle değişebilmelidir.

İlgili terimler

Definition of Done, Product Backlog, Backlog Refinement, Acceptance Criteria, Sprint Planning, Sprint Goal, Product Owner, User Story, Dependency Management, Accessibility, Risk Management, Working Agreement, Technical Spike