Trello Panosundan Haftalık Changelog Üretmek
Trello'dan güvenilir bir haftalık changelog çıkarmanın yolu: işi hangi sinyalin tamamlanmış saydığı, pano ve etiketlerin ürün alanlarına nasıl eşleneceği, geçmiş veri ve webhook kurulumunun nasıl ele alınacağı.
Soobrief Ekibi — Ürün ve Mühendislik, Sooapps ·
Kısaca
Trello panonuz zaten bir changelog içeriyor; eksik olan tek şey bir kartın ne zaman tamamlanmış sayılacağına karar veren kural. Tek bir sinyal seçin (bir Done listesi ya da belirli bir etiket), panoyu ürüne ve etiketi kategoriye eşleyin, kartları bu duruma geçtikleri zaman damgasıyla okuyun. Bu eşleme bir kez kurulduğunda haftalık changelog bir yazma işi değil, bir sorgu hâline gelir.
Trello panosu zaten bir changelog. Tamamlanmış her kart, yayına çıkmış bir işin kaydı: zaman damgası, başlık ve pano biraz olsun düzenliyse örtük bir ürün alanı içeriyor. Kimsenin panoyu changelog gibi kullanmamasının sebebi, bunu elle çıkarmanın yoğun bir haftada ilk elenen iş olacak kadar sıkıcı olması.
Oysa çıkarma işlemi mekanik. Bir kez verilecek üç karar yetiyor.
Karar 1: "tamamlandı" ne demek?
Çıktının güvenilir olup olmayacağını belirleyen karar bu ve çoğu ekibin belirsiz bıraktığı karar da bu.
Tek bir sinyal seçin:
| Sinyal | Ne zaman iyi çalışır | Dikkat edilecek nokta |
|---|
Belirli bir liste (Done, Yayında) | Panoda net bir soldan sağa akış varsa | Done'da unutulmuş ama aslında iptal edilmiş kartlar |
Etiket (yayında, tamamlandı) | Kartlar tamamlandıktan sonra farklı listelerde duruyorsa | Etiketlerin üyeler arasında tutarsız kullanılması |
| Kartı arşivleme | Ekip tamamlandığında düzenli olarak arşivliyorsa | Arşivlemenin temizlik ve mükerrer kart için de kullanılması |
Asıl hata "yanlış" sinyali seçmek değil — üçü de çalışır. Hata, ikisini aynı anda kullanmak. Hem "Done listesinde olması"nı hem "yayında etiketi"ni tamamlanma sayan bir ekip bazı kartları iki kez sayar, bazılarını atlar ve changelog sessizce güvenilmez hâle gelir.
Seçtiğiniz kuralı ekibin görebileceği bir yere yazın. Kural sürecin parçası; teknik bir ayrıntı değil.
Karar 2: pano ve etiketler yapıya nasıl eşlenecek?
Tek düz liste hâlindeki bir changelog, panonun kendisinden pek de iyi değil. Değer gruplamadan geliyor ve Trello muhakeme gerektirmeden bunu yapacak sinyali zaten taşıyor:
- Pano → ürün alanı. Ürün ya da ana yüzey başına bir pano yaygın durumdur ve eşleme doğrudandır.
- Liste veya etiket → kategori.
hata, özellik, altyapı, tasarım — ekibin zaten kullandığı sözlük neyse o.
- Kart başlığı → changelog satırı, tercihen sonuç olarak hafifçe yeniden yazılmış hâliyle.
Bu eşlemeyi resmîleştirmeye değer kılan iki özellik var. Kararlıdır, yani aynı kart her zaman aynı yere düşer ve arka arkaya iki hafta doğrudan karşılaştırılabilir. Ve açıktır, yani bir şey yanlış bölüme düştüğünde çözüm bir yorum tartışması değil, bir eşleme değişikliğidir.
Panolarınız şu anda temiz bir eşlemeyi desteklemiyorsa, bunu bilmek de değerli. Ürün alanlarına eşlenemeyen bir pano, genellikle insanların da okumakta zorlandığı bir panodur.
Karar 3: geçmiş veri mi, sürekli senkron mu?
Bunlar gerçekten farklı işlemler ve karıştırılmaları sorun çıkarıyor.
Geçmiş veri aktarımı (backfill) tek seferlik bir okuma. Bir panoyu bağlıyor ve son N günde tamamlanan her şeyi istiyorsunuz. Trello REST API'sini kullanır, kart hareketlerini sayfalayarak gezer ve her kartın tamamlanmış duruma geçiş zamanını okur. Bir hafta olay birikmesini beklemek yerine hemen kullanışlı bir ilk changelog elde etmenizi sağlayan şey budur.
Sürekli senkron olay tabanlı. Trello webhook'ları kart güncellemelerinde tetiklenir ve entegrasyon tamamlanmaları gerçekleştikçe kaydeder. Bu, panoyu sürekli sorgulamaktan hem ucuzdur hem de geçiş zamanını tahmin etmek yerine doğru biçimde yakalar.
Trello webhook'u kuran çoğu ekibin takıldığı pratik bir ayrıntı: Trello, webhook'u oluşturmadan önce callback adresini bir HEAD isteğiyle doğrular. Adresin kayıt anında HTTPS üzerinden herkese açık erişilebilir olması gerekir. localhost üzerinde çalışan bir API webhook kurulumunu tamamlayamaz — geliştirme sırasında herkese açık bir tünele, üretimde ise gerçek genel origin'e ihtiyacınız var.
İkinci ayrıntı: kartlar geri gider. Bir iş salı günü Done'a düşer, çarşamba yeniden açılır. Doğru davranış, tamamlanmış duruma en son geçişi tamamlanma zamanı saymak ve bu durumdan çıkmış bir kartı aralıktan düşürmek. Güncel pano durumunu okumanın, tek seferlik bir anlık görüntüye güvenmekten daha önemli olmasının sebebi bu.
Hepsini birleştirmek
Bu üç karar verildiğinde haftalık changelog bir sorguya dönüşüyor:
> Pazartesi ile pazar arasında tamamlanmış duruma geçen tüm kartları, pano → etiket sırasıyla gruplanmış ve tamamlanma zamanına göre sıralanmış olarak ver.
Çıktı yapılandırılmış bir belge. Henüz iyi bir changelog değil — kart başlıkları işi yapan kişiler tarafından, yine onlar için yazılmıştır ve ham listeleri bir veritabanı dökümü gibi okunur. Anlatı adımının yerini hak ettiği nokta tam burası: PROJ-4412: davet hatası ifadesini ekip dışından birinin kullanabileceği bir cümleye çevirmek ve listenin üzerine iki üç cümlelik bağlam eklemek.
Sıra önemli. Önce kurallardan gelen yapı. Sonra zaten düzenlenmiş verinin üzerine anlatı. Sırayı ters çevirmek — ham kartları dil modeline verip "bir changelog yaz" demek — okunuşu iyi ama her hafta kendini yeniden düzenleyen bir metin üretir ve ardışık haftaları karşılaştırılamaz kılar.
Soobrief bunu nasıl yapıyor?
Soobrief Trello için tam olarak bu akışı uyguluyor. Bir panoyu ya Trello yetkilendirmesiyle (webhook otomatik kaydedilir) ya da API anahtarı ve token'ı elle girerek bağlıyorsunuz, ardından hangi listelerin tamamlanmış sayılacağını seçiyorsunuz. Sonrası:
- Tamamlanan kartlar webhook ile alınır; geçmiş için backfill mevcuttur.
- Pano ve etiket, deterministik kurallarla ürün ve kategoriye eşlenir; aynı girdi her zaman aynı yapıyı üretir.
- Dil modeli zaten gruplanmış belgeyi alır ve yalnızca anlatıyı yazar. Gruplamaya asla karar vermez.
- Sonuç, bir insan tarafından incelenip düzenlenebilen Markdown'dır.
Trello tam olarak desteklenen ilk kaynak; sırada Jira, ardından genel sağlayıcı entegrasyonu var.
Sıkça sorulan sorular
Bir Trello kartının tamamlandığını nasıl anlarım? Tek bir sinyal seçip tutarlı uygulayın — belirli bir liste ya da özel bir etiket. İki rakip sinyal, eksik ya da mükerrer kalemlerin en sık sebebi.
Birden fazla Trello panosundan changelog üretebilir miyim? Evet. Her panoyu bir ürün alanına, her etiketi bir kategoriye eşleyin; panolar tek bir gruplanmış changelog'da birleşir.
Entegrasyon bağlanmadan önce tamamlanan kartlar dahil olur mu? Evet, geçmiş veri aktarımıyla. Backfill tek seferlik bir okumadır; sonrasını webhook'lar yürütür.
Bir kart Done'a taşınıp geri alınırsa ne olur? Tamamlanmış duruma en son geçiş anını kullanın; bu durumdan çıkan kart yeniden girene kadar aralıktan düşer.
İlgili yazılar: Haftalık ürün güncellemesi nasıl yazılır? · Deterministik gruplama mı, yapıyı yapay zekâya bırakmak mı? · Durum toplantısı olmadan ekip yönetmek