Geriye Dönük Eylem Kalemleri: Takibi Netleştiren Örnekler
Tekrarlayan bir problemi, ekibinizin deneyip, sahiplenip, gözden geçirebileceği tek bir değişikliğe dönüştürün. Bu örnekler ne yazılacağını ve sonrasında nelerin kontrol edileceğini gösterir.

Geriye dönük eylem kalemi, ekibin nasıl işlediğini tartıştıktan sonra gerçekleştirmeyi kabul ettiği spesifik bir gelişmedir. Yararlı bir kayıt; değişikliği, bir sorumluyu ve bir gözden geçirme noktasını belirtir, ardından değişikliğin faydalı olup olmadığını gösterecek kanıtları açıklar.
“Kod incelemelerini geliştirin” ifadesi sonraki adımı belirsiz bırakır. “Gelecek sprint için, her incelemeye hazır pull request’i ortak bir kuyruğa koyun; Maya her iş gününde talep edilmeyenleri kontrol eder; bekleme süresi ve kesintileri bir sonraki geriye dönüşte gözden geçirin” ifadesi ekibin deneyebileceği somut bir adım sunar.
Scrum Guide, geriye dönük toplantıyı kalite ve etkinliği artırma fırsatı olarak tanımlar ve faydalı gelişmelerin hızlıca ele alınmasını önerir. Aşağıdaki kayıt formatı ve örnekler, ek Scrum kuralları değil, pratik önerilerdir.
Bu rehberde
- Altı eylem kalemi örneği
- Sorumlu belirleyin ve çalışma için yer açın
- Tamamlanan bir eylem hâlâ başka bir karara ihtiyaç duyabilir
- Bir eylem kaydını kopyalayın
- Ne olduğunu gözden geçirin
- Bağlamı Agilo’da tutun
Altı geriye dönük eylem kalemi örneği
Bunlar kurgusal yazılım takımı durumlarıdır. Kişiler, zaman kutuları ve gözden geçirme kriterleri bir kararı nasıl netleştireceğinizi gösterir; bunları ekibinizin kapasitesine ve çalışma anlaşmalarına göre uyarlayın. Tüm listeyi benimsemek yerine gözlemlenen bir problemi ele alan bir örneği seçin.
1. İnceleyecek kişi bilinmediği için pull requestler bekliyor
Belirsiz eylem: “Kod incelemelerini hızlandır.”
Spesifik eylem: Gelecek sprint için, yazarlar incelemeye hazır pull requestleri ortak bir kuyruğa ekler. Maya her iş gününde talep edilmeyenleri kontrol eder ve müsait bir inceleyiciden bunları almasını ister. Yazarlar, eksik bağlam veya tamamlanmamış kontrol gibi incelemeyi engelleyen unsurları belirler.
Gözden geçirme: İlk kapsamlı incelemeye kadar geçen süreyi önceki sprint ile karşılaştırın; istek büyüklüğü, inceleyici müsaitliği ve kesintileri not edin. Sadece onaylamak inceleme sayılmaz. Daha hızlı yanıtlar ancak kişiler kodu dikkatle inceleyebiliyorsa faydalıdır.
2. Aynı kararsız kontrol teslimatı sürekli geciktiriyor
Belirsiz eylem: “CI’yi düzelt.”
Spesifik eylem: Bir sonraki planlama oturumundan önce Leo, son iki birleştirmeyi engelleyen ara sıra ortaya çıkan checkout testini araştırır, yeniden üretilebilir bir neden veya daraltılmış bir varsayım kaydeder ve en küçük onarımı önerir. Takım araştırma için zaman ayırır.
Gözden geçirme: Planlamada bulguları inceleyip sonraki kararda anlaşın. Onarımdan sonra, tekrar için sonraki ilgili çalışmaları kontrol edin ve sonucu bir sonraki geriye dönüşte paylaşın. Kontrolü etkisiz hale getirmek veya tek bir başarılı çalışmayı görmek problemi çözdüğünüz anlamına gelmez; gereken kapsamı koruyun.
3. Başka bir takımın API değişikliği çok geç geliyor
Belirsiz eylem: “Platform takımıyla daha iyi koordine ol.”
Spesifik eylem: Bir sonraki entegrasyon öğesine başlamadan önce Priya, platform muhatabından ortak bir örnek istek, yanıt ve hata durumunu incelemesini ister. Kabul edilen varsayımları ve çözülmemiş kararları entegrasyon görevine kaydeder. Muhtaç yoksa, bu bağımlılığı anlaşılmış gibi olmadığını planlamaya taşır.
Gözden geçirme: Bir sonraki geriye dönüşte, üzerinde anlaşılmış örneğin uygulama sırasında geçerli kalıp kalmadığını ve eksik veya değişen varsayımlardan ne tür yeniden işler çıktığını kontrol edin. Toplantı düzenlemek bir adımdır; bağımlılığı çözmek amaçlanan faydadır.
4. Bir hata düzeltmesi devredilirken çoğaltma adımlarını kaybediyor
Belirsiz eylem: “Daha iyi hata raporları yaz.”
Spesifik eylem: Sonraki üç hata düzeltmesi için Sam, devretmeden önce çoğaltma adımlarını, ilgili ortamı ve beklenen davranışı probleme ekler. Geliştirici ve test uzmanı, bu adımlara güvenmeden önce eksik detayları birlikte çözer.
Gözden geçirme: Üçüncü düzeltmeden sonra, alan kişinin özgün sohbeti yeniden oluşturmasına gerek kalmadan her düzeltmeyi çoğaltıp doğrulayabildiğini sorun. Eksik bilgileri, raporları yazanları sıralamadan kaydedin.
5. Destek soruları aynı geliştiriciyi sürekli kesiyor
Belirsiz eylem: “Odaklanma zamanını koru.”
Spesifik eylem: Bir sprint boyunca ekip, rutin destek soruları için dönen bir ilk temas kişisi dener. Noor rotasyonu ve ortak bir alım konumu yayımlar, mevcut acil olay yükseltme yolunu açık tutar. Ekip, destek veren kişi için zaman ayırır.
Gözden geçirme: Bir sonraki geriye dönüşte, ekipteki kesintilere ve yanıtlanmamış isteklere bakın. Eğer tek bir kişi tüm kesintileri üstleniyorsa veya önemli istekler daha uzun süre bekliyorsa düzenlemeyi değiştirin. Sadece bir geliştiricinin gelen kutusundaki mesaj sayısının azalması başarı göstergesi değildir.
6. Başarısız dağıtımı sadece bir kişi nasıl kurtaracağını biliyor
Belirsiz eylem: “Daha fazla bilgi paylaş.”
Spesifik eylem: Bir sonraki sürümden önce Alex, onaylı bir üretim dışı ortamda başka bir geliştiriciyle kurtarma prosedürünün provalarını düzenler. İkinci kişi mevcut notları takip eder ve eksik adımları kaydeder; Alex provayı yönetir ve talimatları bu bilgilerle günceller.
Gözden geçirme: Provadan sonra, ikinci kişinin kurtarma kararını açıklayıp yazılı olmayan rehberlik olmadan provayı uygulayıp uygulayamadığını kontrol edin. Sadece bir dokümanın varlığı yeterli değildir. Bu egzersiz, üretim erişiminizi veya değişiklik onay kurallarınızı değiştirmez.
Bir sorumlu seçin ve çalışma için yer açın
Bir sorumlu, sonraki adımı görünür tutar, yardım toplar ve kanıt getirir. O kişi her görevi yapmak zorunda değildir veya herkesin davranışından sorumlu olmaz. Eylemi kabul ettiğini ve etkileyebileceğini doğrulayın.
Ekip destekleyebiliyorsa bir veya iki değişiklikle başlayın. Bu bir kapasite kararıdır, evrensel bir sınır değil. Bir eylem eklemeden önce ne kadar zaman gerektiği ve teslimat işleriyle birlikte nerede takip edileceği üzerinde anlaşın. Bir araştırma açık bir görev gerektirebilir; değişen bir devretme kuralı mevcut görev tanımına uyabilir.
Bir değişiklik başka bir takım veya yöneticinin onayına bağlıysa, talep ve karar noktasını açıkça belirtin. Bir sorumlu karar aramayı taahhüt edebilir; başkasının onayını garanti edemez.
Değiştirilecek veya korunacak uygulamalar tartışılırken Start Stop Continue şablonunu kullanın. Bir “Başla” notu, ekip eylem üzerinde anlaşana ve ona yer açana kadar hâlâ bir öneridir.
Tamamlanmış bir eylem hâlâ başka bir karara ihtiyaç duyabilir
İnceleme kuyruğu örneğine dönelim. Ekip iki farklı kontrol kaydeder:
| Kontrol | Getirilecek Kanıt |
|---|---|
| Anlaşmayı uyguladık mı? | İncelemeye hazır istekler kuyruğa alındı, talep edilmeyen işler kontrol edildi ve boşluklar kaydedildi |
| Yardımı oldu mu? | Bekleme süresi, istek büyüklüğü, inceleyici müsaitliği, kesinti notları ve inceleme kalitesi geri bildirimi |
Ekip sprint boyunca kuyruğu kullansın, ancak tek bir servisi bilen kişi uygun olmadığında istekler beklemeye devam etsin. Bu kurgu bir sonuçtur, Agilo müşterisi tarafından raporlanan bir durum değildir.
Kuyruk deneyi yapıldı. Ekip, sadece görünürlüğün uzman darboğazını çözmediğini öğrendi. Sonraki karar, bu hizmet için başka bir geliştiriciyi incelemelerde eşleştirmek olabilir; kuyruk faydalı kalırsa tutulur. “Tamamlandı”, kararlaştırılan işin tamamlandığını ifade eder; altta yatan sorunun otomatik olarak ortadan kalktığı anlamına gelmez.
Sadece birkaç benzer istek geldi ise, kanıtın sınırlı olduğunu belirtin. Değişikliğin başarılı ya da başarısız olduğunu iddia etmeden bir sprint daha gözlemlemeyi seçebilirsiniz.
Bu retrospektif eylem kaydını kopyalayın
Bunu mevcut görev takipçinizde veya takım notlarınızda kullanın. Eyleme değişikliği tanımlayan bir başlık verin, ardından gerekçesini yanında tutun.
Gözlem ve kaynak:
Deneyeceğimiz değişiklik:
Bunu kabul eden sorumlu:
Gerekli kişiler veya kararlar:
İlk adım ve ayrılan süre:
Ne zaman inceleyeceğiz:
Eylemin gerçekleştirildiğine dair kanıt:
Yardımcı olduğuna dair kanıt, olası yan etkiler dahil:
İnceleme sonrası karar: sürdür / ayarla / durdur / daha fazla kanıt topla
İnceleme kuyruğu için ilk adım, taleplerin sprint başlamadan önce nereye gideceği üzerinde anlaşmak olabilir. İnceleme noktası bir sonraki retrospektif olabilir; sprint sırasında talepler karşılanmamışsa kısa bir kontrol yapılır. "Daha sonra" yerine takımınızın tekrar bulabileceği gerçek bir tarih veya etkinlik kullanın.
Yeni eylemler eklemeden önce olanları inceleyin
Anlaşılan kontrolde, sorumlu kişiden işi tanımlamasını ve mevcut kanıtları göstermesini isteyin. Koşullar ve kararlarla ilgili tartışmayı sürdürün; takımın söz verilen zamanı ayırıp ayırmadığını da dahil edin.
| Ne oldu | Faydalı bir sonraki karar |
|---|---|
| Değişiklik faydalı ve uygulanabilir oldu | Uygulamayı sürdürün ve devam eden anlaşmanın nerede olduğunu kaydedin |
| Eylem tamamlandı ancak sorun devam ediyor | Sorunun açıklamasını yeniden gözden geçirin ve sonraki deneyi değiştirin |
| İş başlayamadı | Kapasite, erişim veya bağımlılık eksikliğini belirleyin; daha küçük bir adım, yeni taahhüt veya kasıtlı iptal üzerinde anlaşın |
| Takım denedi ama yeterli kanıt yok | Ne gözlemleneceğini ve yeni bir inceleme noktası seçin |
| Değişiklik başka bir sorun yarattı | Ayarlayın veya durdurun ve takasları kaydedin |
Koşulları değiştirmeden aynı eylemi sürdürmek, sonraki sprint için aynı çözülmemiş taahhüdü verir. Karar durdurmak bile olsa, yeni kararı görünür kılın.
Hazırlık ve önceliklendirme dahil tam toplantı dizisi için sprint retrospektifi kolaylaştırma kılavuzu kullanın.
Retrospektif eylem öğeleri hakkında sorular
Her retrospektif notunun bir eyleme ihtiyacı var mı?
Hayır. Notlar işe yarayan bir şeyi koruyabilir, bir soru ortaya atabilir veya bağlam sağlayabilir. İyileştirmeleri, takımın öğrendiklerine ve etkileyebileceklerine göre seçin. Her notu göreve dönüştürmek, dikkati hak eden birkaç değişikliği gizleyebilir.
Tüm eylemlerin sahibi Scrum Master mı olmalı?
Her değişikliği ilerletebilecek bir sorumlu seçin. Bir kolaylaştırıcı, her iyileştirmenin sorumlusu olmadan takımın anlaşmalar yapmasına ve gözden geçirmesine yardımcı olabilir. Yapı davranışıyla ilgili bir eylem geliştirici gerektirebilir; dış bağımlılıklar hakkında bir karar, ilgili takıma ulaşabilecek biri gerektirebilir.
Bir araştırma eylem maddesi olabilir mi?
Evet, belirsizlik mantıklı bir değişikliği engellediğinde. Soruyu, ayrılan zamanı ve bulguların bilgilendireceği kararı belirtin. “Yavaş incelemeleri araştır” belirsiz kalır; “üç gecikmiş isteğin nerede beklediğini belirle ve önerilen değişikliği iyileştirmeye getir” sınırlandırılmış bir sonuç sunar.
Gözlemi ve eylemi Agilo’da birlikte tutun
Agilo Retrospectives içinde, bir eylem öğesi başlık, açıklama, görevli, öncelik ve duruma sahip olabilir ve kaynak kartına bağlanabilir. Anlaşılmış inceleme noktasını ve toplanacak kanıtı açıklamaya ekleyin; inceleme sırasında gözlemlenen sonucu bir yorum olarak ekleyin.
Bu, çalışmanın gerekçesini ilerlemesiyle birlikte korur. Takım, değişikliğin yardımcı olup olmadığını ve sonraki adımı hala karar verir.
Bir retrospektif oluşturun ve takımınızın gerçekleştirmeye hazır olduğu bir gözlemi eyleme dönüştürün.
