Gönderiler

Ekibinizin gercekten ihtiyaci olan definition of done kontrol listesi

Her Scrum ekibinin, birinin bir hikayeyi "tamamlandi" olarak isaretledigi ve bir baskasinin "ama testleri yazdin mi?" diye sordugu bir ani vardir. Bir kisinin tamamlanmis olarak kabul ettigi sey ile ekibin gercekte ihtiyac duydugu sey arasindaki bu bosluk, tam olarak Definition of Done'in cozdugu problemdir. 2020 Scrum Kilavuzu, DoD'yi sahip olunmasi guzel bir seyden, Artis'a bagli resmi bir taahhude yukseltti. Ancak Ron Lichty'nin Urun Ekibi Performansi Arastirmasi, ekiplerin yalnizca %45'inin kendi ekipleri tarafindan olusturulmus bir DoD'ye sahip oldugunu gostermektedir. Geri kalani ya DoD olmadan calisiyor ya da baska birinin verdigi bir kontrol listesini takip ediyor. Ilginc olan kisim: yalnizca ekip tarafindan olusturulan definition of done'lar yuksek performansla iliskilendirilmektedir. Disaridan dayatilan DoD'ler hicbir korelasyon gostermemektedir.

Definition of done aslinda nedir

DoD, ekibinizin teslim ettigi her is parcasina uygulanan paylasilan bir kalite standardidir. Kabul kriterleriyle ayni sey degildir.

	Definition of Done	Kabul kriterleri
Kapsam	Evrensel, tum islere uygulanir	Tek bir hikayeye ozgu
Odak	Kalite ve surec standartlari	Fonksiyonel gereksinimler
Kim yazar	Tum Scrum Ekibi	Urun Sahibi (ekip girdisiyle)
Ornek	"Kod en az bir gelistirici tarafindan incelendi"	"Kullanici tarih araligina gore filtreleyebilir"

Bir hikaye tamamlanmadan once her ikisinin de karsilanmasi gerekir. Kabul kriterleri neyi insa edeceginizi soyler. DoD, ne kadar iyi insa edilmesi gerektigini soyler.

Uc seviyede definition of done kontrol listesi

Her ekip ayni DoD'ye ihtiyac duymaz. MVP'sini gondermekte olan bir startup, uyumluluk gereksinimleri olan bir saglik platformundan farkli kalite ihtiyaclarina sahiptir. Iste katmanli bir yaklasim.

Baslangic DoD

Resmi bir definition of done ile yeni baslayan ekipler icin:

Orta Seviye DoD

Yerlesik CI/CD'ye sahip ve birkaç sprint deneyimi olan ekipler icin:

Ileri Seviye DoD

Her sprintte production'a deploy eden olgun ekipler icin: Dogru seviye bağlaminiza baglidir. Ekibinizin surekli olarak karsilayabilecegi bir kontrol listesiyle baslayin, sonra zamanla citiyi yukseltin. Ekibinizin rutin olarak atladigi maddeleri eklemek, herkesi DoD'yi tamamen gormezden gelmeye alistirmaktan baska bir ise yaramaz.

DoD'nin tahminleme icin sandiginizdan daha onemli olmasi

Cogu definition of done makalesi burada durur. Ancak DoD ile tahmin dogrulugu arasindaki baglanti, dogru yapmanin en hafife alinan nedenidir. Scrum Kilavuzu bunu acikca belirtir: gelistiriciler Definition of Done'larini anladiklarinda daha guvenle tahmin yaparlar. Ekibiniz planning poker sirasinda bir hikayeyi tahmin ettiginde, bu tahmin DoD'yi karsilamak icin gereken her seyi icermelidir. Sadece kodu yazmak degil, inceleme, testler, deploy ve geri kalan her sey. Yalnizca kodlama eforu tahmin eden ve sonra sprint sonunda DoD aktivitelerini kesfeden ekipler surekli olarak fazla taahhut eder. Is tahmin edilenden uzun surmedi. Tahmin isin yarisini gormezden geldi. DoD'nize yeni maddeler eklediginizde (guvenlik taramasi veya performans testi gibi), velocity'nin gecici olarak dusmesini bekleyin. Bu sagliklidir. Velocity'niz sadece durustlesiyor.

DoD'nizi baltalayan bes anti-kalip

1. Yaz ve unut

Ekip alti ay once bir DoD yazdi ve o zamandan beri bakmadi. Araclar degisiyor ve urun buyuyor. Her seferinde degistirmeseniz bile DoD'yi retrospektiflerinizde gozden gecirin.

2. Tek bir kisi tarafindan olusturuldu

Bir teknik lider veya Scrum Master, DoD'yi tek basina hazirlar ve kesinlesmis olarak sunar. Ekibin geri kalani uzerinde hicbir zaman sahiplik hissetmez, bu yuzden opsiyonel olarak gorurler. Cozum: birlikte bir calismada olusturun. Isi yapan herkesin "tamamlandi"nin ne anlama geldiginde sozu olmalidir.

3. Dogrulanamayacak kadar belirsiz

"Kod kaliteli" ve "test yapildi" dogrulanabilir ifadeler degildir. Her maddenin net bir gecti/kaldi kosulu olmalidir. "Kod statik analizden sifir kritik sorunla gecti" kontrol edilebilir bir seydir. "Kod temiz" bir gorus meselesidir.

4. Baski altinda citayi dusurme

Teslim tarihleri sikistiginda, ekipler bazen daha hizli gondermek icin DoD'yi zayiflatir. 2020 Scrum Kilavuzu burada aciktir: DoD kaliteyi iyilestirmek icin gelisebilir, ancak zayiflatilmamalidir. Kaliteden odun vermek sizi hizlandirmaz. Gelecek sprintler icin sorunlar yigarak hiz yanilsamasi yaratir.

5. DoD ile kabul kriterlerini karistirma

DoD evrenseldir. Kabul kriterleri hikayeye ozgudur. Bunlari birbirine karistirmak, ya kalite standardini kaybedersiniz ya da fonksiyonel gereksinimleri unutursunuz anlamina gelir. Bunlari birlikte calisan ayri kontrol listeleri olarak tutun.

Ilk DoD'nizi nasil olusturursunuz

Ekibinizin henuz bir definition of done'i yoksa, istte olusturmak icin pratik bir yol. Hizli bir baslangic noktasi icin, bir definition of done olusturucu ekibinizin baglamina gore bir baslangic kontrol listesi hazirlayabilir.

1. Halihazirda yapilanlari belirleyerek baslayin

   Ekibinize sorun: "Bir seyi tamamlandi olarak adlandirmadan once zaten ne yapiyoruz?" Her cevabi yazin. Cogu ekibin zaten belgelenmemis gayri resmi standartlari vardir.

2. Bosluklari belirleyin

   Son hatalara veya production olaylarina bakin. Bunlari daha erken ne yakalayabilirdi? Bu bosluklar yeni DoD maddeleri icin aday olur.

3. Kisa tutun

   6-12 madde hedefleyin. Her madde gercek bir sorun kategorisini onleyerek yerini hak etmelidir. Bir maddenin yakalayacagi belirli bir soruna isaret edemiyorsaniz, cikartin.

4. Gorunur kilin

   DoD'yi ekibin sprint planlama ve gunluk calisma sirasinda gorebilecegi bir yere koyun. Bir wiki'ye gomulmus bir kontrol listesi, kimsenin okumadigi bir kontrol listesidir.

5. Her retrospektifte gozden gecirin

   Retrospektiflerinize surekli bir gundem maddesi ekleyin. Sorun: "DoD yakalamasi gerekeni yakaladi mi? Bir sey gozden mi kacti? Madde eklemeli veya cikarmali miyiz?"

Yuksek performansli ekipler neleri farkli yapar

Ron Lichty'nin arastirmasi net bir kaliba isaret ediyor. Yuksek performansli ekipler DoD'lerine sahip cikar ve bilinçli olarak gelistirir. Ayrica tahminlemeyi iyimser degil, durustturmak icin kullanirlar. Bu ekipler kontrol listesinin mumkun oldugunca cogunu otomatiklestirir. Kod kapsami kontrolleri ve statik analiz, guvenlik taramalariyla birlikte CI/CD pipeline'larinda calisir. DoD, hafiza yerine sistem tarafindan uygulanir, bu da ekibi gercekten insan yargilamasi gerektiren maddelere odaklanmaya serbest birakir; ornegin kabul kriterlerinin kullanici perspektifinden karsilanip karsilanmadigi. En olgun ekipler DoD'lerini yalnizca teknik standartlara degil, is sonuclarina baglar. Martin Hinshelwood bir ornek verir: "Production'da canli, telemetri toplayan, baslangic hipotezini destekleyen veya azaltan." Bu, definition of done'i yalnizca "kod calisiyor" degil, "gonderdigimiz seyden ogreniyoruz" olan bir ekiptir.

Baslangic

Yukaridaki baslangic kontrol listesinden uc madde secin. Bunlari bir beyaz tahtaya yazin veya paylasilan bir dokumana ekleyin. Bir sprint boyunca kullanin. Retrospektifte neyin isleyip neyin eksik oldugunu sorun. Bir veya iki madde ekleyin. Tekrarlayin. Ekibin gercekten takip ettigi kucuk, tutarli bir DoD, herkesin gormezden geldigi kapsamli bir DoD'yi yener. Once aliskanliği olusturun, sonra citayi yukseltin. Ve bir dahaki sefere biri bir hikayenin tamamlanip tamamlanmadigini sorduğunda, 10 dakikalik bir konusma gerektirmeyen bir cevabniz olacak. Ekibiniz tahminleme icin planning poker kullaniyorsa, bu oturumlar sirasinda DoD'yi gorunur tutun. Tahminlerin "tamamlandi"nin gercekte ne anlama geldiginin tam kapsamini yansitmasini saglamanin en hizli yoludur.