30 saniyelik özet

Increment, önceki ürün durumuna eklenen ve kullanılabilir olan somut ürün artışıdır. Definition of Done, yani tamamlanmış sayılma tanımındaki kalite koşullarını karşılamalıdır. Release, değişikliğin kullanıcılara sunulmasıdır. Release Planning, yani sürüm planlama, sunulacak kapsamı, kullanıcı grubunu, zamanlamayı ve gerekli hazırlıkları ele alır. Bu ayrım, geliştirme ilerlemesini müşteriyle kurulan sözle ilişkilendirmeye yardımcı olur. Tamamlanmış ürün artışı, uygun koşullarda sunulabilir; eksik kalite çalışmalarını “Yayımlarken bitiririz” diyerek ertelemek ayrı bir durumdur. Sağlam bir plan, yayımlama tarihinin yanında değerlendirme ve sorun halinde müdahale kararlarını da açıklar.

Neden önemli?

Bir faturalama değişikliğinin testleri tamamlanmış olabilir. Fakat müşterilere hangi faturanın geçerli olduğu anlatılmamışsa, destek ekibi itirazları nasıl ele alacağını bilmiyorsa veya veri geçişinin sorumlusu belli değilse sunum kararı hâlâ hazırlık gerektirebilir. Geliştirme tamamlanmasıyla ticari ve operasyonel hazırlık aynı soruyu cevaplamaz.

Bu fark, yönetim raporlarında da görünmelidir. “Özellik hazır” ifadesi, satış ekibi için hemen müşteriye söz verilebileceği anlamına gelebilir. Mühendislik ekibi ise yalnızca doğrulanmış bir değişiklikten söz ediyor olabilir. Aynı ifadeye farklı anlamlar verilmesi, takvim ve kapsam anlaşmazlıklarını büyütür.

Sürüm planı bu beklentileri ortaklaştırabilir. Hangi kullanıcı yeni davranışı görecek? Mevcut müşterinin iş akışı değişecek mi? Geçiş öncesinde bilgi vermek gerekiyor mu? Sunum aşamalarının ilerlemesine hangi kanıtla karar verilecek? Soruların cevapları, yalnızca teknik ekibin takviminden çıkarılamaz.

Product Owner, yani ürün sahibi, beklenen kullanıcı değerini ve kapsam seçeneklerini açıklarken mühendislik, destek ve ilgili iş birimleri kendi sorumluluklarını görünür kılmalıdır. Örneğin finansal veriyi etkileyen bir değişiklikte finans ekibinin katkısı gerekir. Bu, her küçük değişiklik için kalabalık bir onay zinciri kurulmasını gerektirmez; etkiye uygun hazırlık yapılmasını gerektirir.

Yönetici açısından amaç, bütün belirsizlikleri ortadan kaldırmak değildir. Hangi riskin kabul edildiğini, hangi verinin izleneceğini ve sorun çıkarsa kimin karar vereceğini bilmektir. Böylece plan, tarih yazılı bir duyurunun ötesine geçerek uygulanabilir bir karar çerçevesi oluşturur.

Terim nedir?

Scrum, karmaşık ürün çalışmalarını yönetmeye yardımcı olan bir çerçevedir. 2020 Scrum Guide’a göre Increment, önceki ürün artışlarına eklenir ve bunlarla birlikte çalıştığı doğrulanır. Değer sağlayabilmesi için kullanılabilir olmalıdır. Tamamlanma koşullarını karşılamayan çalışma Increment’ın parçası sayılamaz.

Sprint, bir ayı aşmayan sabit süreli çalışma döngüsüdür. Aynı Sprint içinde birden fazla Increment oluşturulabilir. Bunlar döngü bitmeden de sunulabilir. Sprint Review, sonuçların ve sonraki uyarlamaların değerlendirildiği etkinliktir; yayımlamayı bekleten bir onay kapısı değildir.

Çerçeve kaynağı: Ken Schwaber ve Jeff Sutherland, The Scrum Guide, Kasım 2020.

Release Planning için her üründe aynı ayrıntı düzeyini kullanmak gerekmez. İç kullanımda küçük bir iyileştirmeyle müşterilerin ödeme davranışını değiştiren bir sürümün hazırlıkları farklı olabilir. Sunum amacı, etkilenen kullanıcılar, bağımlılıklar ve müdahale seçenekleri bu kapsamı belirlemeye yardımcı olur.

Deployment, yazılım değişikliğinin çalışacağı ortama taşınmasıdır. Kullanıcıya açılma zamanı bundan ayrı yönetilebilir. Feature Flag, bir davranışı kodu yeniden yayımlamadan belirli koşullarda açıp kapatmaya yarayan kontrol mekanizmasıdır. Ancak bu mekanizma veri değişikliklerini kendiliğinden geri almaz. Özelliği kapatmakla eski duruma güvenli biçimde dönmek aynı şey olmayabilir.

Gerçek vaka: LinkedIn’de sürekli dağıtıma geçiş

LinkedIn’in 18 Ekim 2019 tarihli mühendislik yazısı, otomatik doğrulama ve dağıtım düzeninin geliştirilmesini anlatıyor. Continuous Deployment, yani sürekli dağıtım, doğrulamaları geçen kod değişikliklerinin üretim ortamına otomatik taşınması yaklaşımıdır.

Yazıda kod kalitesi, bütünleşme testleri ve üretim öncesi doğrulama ayrı çalışma alanları olarak ele alınıyor. İnceleme süreci ve test altyapısı geliştirilmiş. LinkedIn ayrıca canary testing kullanıyor: Yeni sürüm sınırlı bir kullanıcı grubuna sunuluyor, üretilen ölçümler kontrol grubuyla karşılaştırılıyor. Sorun saptandığında değişiklik geri alınıyor.

Ekip, önemli servislerde yayımlama sıklığının haftada birkaç sürümden günde birden fazla sürüme çıktığını bildiriyor. Bu, yazarın aktardığı sonuçtur; bütün LinkedIn ürünleri için genellenemez. Yazı müşteri değerindeki değişimi aynı ölçüyle kanıtlamıyor ve Scrum Increment uygulamasına ilişkin bir vaka sunmuyor.

Buradaki ilgili ders, küçük değişiklikleri sunma kabiliyetinin doğrulama ve müdahale düzeniyle birlikte geliştirilmesidir. “Daha sık yayımlayalım” kararı, tek başına bu kabiliyeti oluşturmaz. Sunum riskini yönetmek için gerekli kanıtların ve geri dönüş seçeneklerinin de hazırlanması gerekir.

Kaynak: LinkedIn Engineering, Learnings from the journey to continuous deployment, Gururajan R., 18 Ekim 2019.

Varsayımsal örnek: Fatura görünümünü aşamalı sunmak

Bir kurumsal yazılım ürünü, müşterilerin faturadaki ücret kalemlerini daha kolay anlamasını istiyor. İlk ürün artışı, mevcut hesaplama sonuçlarını daha açıklayıcı bir görünümle sunuyor. Ücret hesaplama kuralları bu kapsamda değişmiyor. Böylece ekip, görsel açıklık ihtiyacını hesaplama motorunu yenilemekten ayrı değerlendirebiliyor.

Geliştiriciler görünümün gerekli kalite koşullarını karşıladığını doğruluyor. Ürün sahibi ve destek ekibi, örnek faturaları inceleyerek müşteriye verilecek açıklamayı hazırlıyor. Yeni görünümün hangi hesaplarda açılacağı, geri bildirimleri kimin toplayacağı ve müşteri sorularının nereye yönlendirileceği belirleniyor.

İlk sunum için uygun müşteriler seçiliyor. Feature Flag sayesinde yeni görünüm bu gruba açılırken diğer müşteriler mevcut görünümü kullanıyor. Her aşamada teknik doğruluk ve kullanıcı anlayışı ayrı inceleniyor. Hata görülmemesi, açıklamaların anlaşılır olduğunu tek başına göstermiyor.

Ekip, fatura kalemlerinin tutarlılığını, görüntüleme hatalarını ve destek görüşmelerinde tekrar eden soruları izliyor. Başlangıç verisi görülmeden başarı oranı veya tasarruf hedefi uydurulmuyor. Yayılımı genişletme koşulları, eldeki veriye ve kabul edilen riske göre açıklanıyor.

Yanlış kalem gösterimi saptanırsa yeni görünümü kapatma kararı uygulanabilir. Bu örnekte hesaplama değişmediği için geri dönüş daha sınırlıdır. İleride hesaplama veya kayıt yapısı değiştirilecekse veri düzeltme ve eski sürümle uyumluluk ayrıca planlanmalıdır. İlk sürümde çalışan yöntem, sonraki sürüm için otomatik güvence sayılmaz.

Yaygın üç hata

  1. Her Sprint sonunu otomatik yayımlama tarihi saymak

Çalışma döngüsü ile kullanıcıya sunum koşullarını ayrı değerlendirin. Hazır ve kullanılabilir değişikliği gereksiz yere bekletmeyin; eksik kalite işini de takvim geldi diye sunmayın. Zamanlama kararının gerekçesini açık tutun.

  1. Planı tarih ve özellik listesinden ibaret bırakmak

Sunulacak kapsamın yanında kullanıcı grubunu, iletişimi, bağımlılıkları ve sorun halinde müdahaleyi açıklayın. Özellikle veri geçişi veya değişen iş akışlarında sorumluların belli olduğundan emin olun.

  1. Geri almayı yalnızca eski kodu yüklemek sanmak

Yeni sürüm veri yazdıysa eski kod bu veriyi okuyamayabilir. Geri dönüşü ürünün veri ve süreç etkisiyle değerlendirin. Özelliği kapatma, dağıtımı geri alma ve veriyi düzeltme seçeneklerini birbirine karıştırmayın.

Mini uygulama / şablon

Yaklaşan bir sunum için aşağıdaki alanları birlikte doldurun.

Beklenen kullanıcı değeri
—
Tamamlanan ürün artışı ve kalite kanıtı
—
Sunulacak kapsam ve kapsam dışı işler
—
Hedef kullanıcılar ve ilk sunum grubu
—
Teknik ve operasyonel bağımlılıklar
—
İletişim, eğitim ve destek hazırlığı
—
Veri geçişi ve uyumluluk ihtiyacı
—
İzlenecek teknik ve kullanıcı göstergeleri
—
Yayılımı genişletme koşulları
—
Durdurma ve geri dönüş koşulları
—
Karar sorumluları
—
Sunum sonrası değerlendirme zamanı
—

Ardından olası bir sorun seçin. Beklenmedik veri oluşursa ne yapacaksınız? Destek talepleri yeni bir kullanım güçlüğü gösterirse yayılımı kim durduracak? Cevapları plan üzerinde yürütün. Belirsiz kalan adımları düzeltin. Planı yalnızca yayımlamadan önce okumak yerine, sonuçlar geldikçe güncelleyin.

İlgili terimler

Definition of Done, Sprint Review, Sprint Goal, Product Goal, Product Backlog, Deployment, Continuous Delivery, Continuous Deployment, Feature Flag, Progressive Delivery, Canary Release, Rollback, Monitoring, Acceptance Criteria, Outcome ve Output