GitHub’un Mühendislik Sistemi Başarı Rehberi

• Mühendislik başarısı için kalite (Quality), hız (Velocity) ve geliştirici memnuniyeti (Happiness) olmak üzere üç alanın uyum içinde olması önemlidir
• ESSP (Engineering System Success Playbook), bunları bütüncül biçimde iyileştirerek iş sonuçlarını en üst düzeye çıkarmak için 3 aşamalı bir çerçeve sunar
• SPACE, DevEx, DX Core 4, DORA gibi çeşitli çerçeveler temel alınarak tasarlanan 12 temel metrik ile organizasyonun mevcut durumu anlaşılır, iyileştirme hedeflerine göre öncelikler belirlenir ve kademeli olarak değişim uygulanıp ayarlanır
  • Bu 12 metrik, her alanı nicel olarak izleyebilecek şekilde yapılandırılmıştır ve her organizasyonun koşullarına göre özelleştirilebilir
• Tüm iyileştirmeler, ekip düzeyinde sürdürülebilirlik ve sistem odaklı düşünme temelinde ilerler; öncü göstergeler ve sonuç göstergeleri birlikte ele alınan dengeli bir yaklaşım vurgulanır
• Hızlı iyileştirmeler yerine sürdürülebilir, uzun vadeli değişim hedeflenir
• ESSP, özel ölçüm araçları olmadan da başlatılabilir; anket gibi nitel yöntemlerle yapılan ilk değerlendirmeler de faydalıdır
• GitHub, kendi örnekleri üzerinden kalite odaklı iyileştirmelerin sonunda hız ve geliştirici memnuniyeti üzerinde de olumlu etki yarattığını vurgular

GitHub’un mühendislik başarı metrikleri

• Quality
  • Change failure rate: değişiklik başarısızlık oranı
    → Arızaya ya da soruna yol açan değişikliklerin oranı
    • Hesaplama: (başarısız dağıtım sayısı / toplam dağıtım sayısı) × 100
    • İpucu: Hangi ölçüte göre başarısız sayılacağının ekip içinde net biçimde kararlaştırılması gerekir (ör. rollback yapılıp yapılmadığı, izleme uyarıları vb.)
  • Failed deployment recovery time: başarısız dağıtımın toparlanma süresi
    → Başarısız bir dağıtımın geri alınması veya sistemin normal duruma döndürülmesi için geçen süre
    • Hesaplama: Her başarısız dağıtım için toparlanmanın tamamlandığı zaman − başarısızlığın gerçekleştiği zaman değerlerinin medyanı
    • İpucu: Uyarı sistemi veya loglardan otomatik çıkarım önerilir. Ortalama yerine medyan kullanılması tavsiye edilir (uç değerlerin etkisini azaltmak için)
  • Code security and maintainability: kod güvenliği ve sürdürülebilirliği
    • Hesaplama: Statik analiz araçları, GitHub Advanced Security, CodeQL vb. ile açık sayısı, karmaşıklık, kapsama oranı gibi verilerin toplu değerlendirilmesi
    • İpucu: Düzenli otomatik taramalar ayarlayın. Refactoring veya güvenlik politikası değişikliklerinin etkisini ölçmek için kullanılabilir
• Velocity
  • Lead time: lead time
    → Bir kod değişikliğinin production’a yansımasına kadar geçen süre
    • Hesaplama: PR’nin açıldığı andan merge edilip dağıtılmasına kadar geçen süre
    • İpucu: Ortalama yerine medyan kullanmak sapmayı azaltır. Lead time uzunsa PR bekleme süresi veya review gecikmesi ayrıca ölçülebilir
  • Deployment frequency: dağıtım sıklığı
    → Production dağıtımının ne kadar sık yapıldığı
    • Hesaplama: Belirli bir dönem içindeki dağıtım sayısı (günlük/haftalık)
    • İpucu: Otomatik dağıtımların dahil edilip edilmeyeceği netleştirilmeli; küçük ekiplerde haftalık ölçüm daha uygun olabilir
  • PRs merged per developer: geliştirici başına merge edilen PR sayısı
    • Hesaplama: Toplam merge edilen PR sayısı / katkı veren geliştirici sayısı
    • İpucu: Karşılaştırma aracı olarak değil, ekip iş akışı verimliliğini ölçmek için kullanılmalıdır. PR boyutu ve karmaşıklığıyla birlikte yorumlanması gerekir
• Developer Happiness
  • Flow state experience: akış durumunu deneyimleme
    • Hesaplama: Geliştirici anketlerinde “son dönemde akış deneyiminin sıklığı/süresi”nin değerlendirilmesi
    • İpucu: Ayda en az 1 kez düzenli anket önerilir. Serbest yanıt alanları eklenirse nitel içgörü de elde edilebilir
  • Engineering tooling satisfaction: mühendislik araçlarından memnuniyet
    • Hesaplama: Geliştirici anketleriyle araç kullanım memnuniyeti ve iyileştirme taleplerinin toplanması
    • İpucu: Araç bazında ayrıntılı başlıklar (IDE, CI, issue tracking vb.) kullanılırsa somut iyileştirme noktaları çıkarılabilir
  • Copilot satisfaction: Copilot kullanım memnuniyeti
    • Hesaplama: Copilot lisansı olanlara yönelik memnuniyet anketi (NPS veya puan)
    • İpucu: İlk kullanımın hemen ardından ve 3 ay sonra gibi farklı zaman noktalarında karşılaştırma yapılması önerilir. Geri bildirimlerle eğitim ve kullanım örnekleri iyileştirilebilir
• Business Outcomes
  • AI leverage: yapay zekadan yararlanma düzeyi
    • Hesaplama: Copilot kaynaklı commit oranı, yapay zeka kod önerilerinin benimsenme oranı, kullanım süresi vb.
    • İpucu: GitHub’un Copilot Telemetry API’si veya dahili ölçüm altyapısı kullanılabilir. Nitel geri bildirimle birlikte analiz edildiğinde daha anlamlı olur
  • Engineering expenses to revenue: mühendislik maliyetlerinin gelire oranı
    • Hesaplama: mühendislikle ilgili harcamalar / toplam gelir
    • İpucu: İç muhasebe ölçütlerinin düzenlenmesi gerekir. Karşılaştırma için aylık veya çeyreklik trend analizi önerilir
  • Feature engineering expenses to total engineering expenses: özellik geliştirme maliyetlerinin toplam mühendislik giderleri içindeki payı
    • Hesaplama: (özellik geliştirmeyle ilgili harcamalar / toplam mühendislik harcamaları)
    • İpucu: Bakım, altyapı, test gibi özellik dışı maliyetlerin sınıflandırma ölçütleri önceden netleştirilmelidir; ancak bu şekilde doğru ölçüm yapılabilir

[Mühendislik başarısı için 3 adım]

Adım 1: Başarıyı engelleyen mevcut bariyerleri belirleyin

• Mevcut geliştirme sürecindeki sorunları ve mühendislik başarısının önündeki engelleri belirlemek temel unsurdur
• Bu, gelecekteki iyileştirme yönünü ve önceliklerini belirlemek için bir başlangıç çizgisi (baseline) işlevi görür
• Yaklaşım
  • Darboğaz noktalarını tespit etmek için SDLC (Software Development Life Cycle) sürecinin tamamı analiz edilir
  • GitHub, analizi 12 standart göstergeye göre yapar; ancak bunların yalnızca bir kısmı kuruluşun özelliklerine göre kullanılabilir
• Ekip katılımı
  • Tek bir lider yerine, iyileştirme sürecini tüm ekip üyeleri birlikte tanımlamalıdır
  • Yalnızca birkaç göstergeyle anlamlı bir sohbet başlatmak bile yeterlidir
• Metodoloji

  • 1. Temel akışı anlama

    • Genel mühendislik akışı şu şekilde bölünerek incelenir:
      • Planlama (Plan) → Geliştirme (Develop) → İnceleme (Review) → Build → Test → Sürümleme (Release) → Operasyon (Operate)

  • 2. Nicel sinyaller toplama

    • Aşağıdaki gibi nicel veriler analiz edilir:
      • Dağıtım sıklığı: Ne kadar sık dağıtım yapılıyor
      • Lead time: Kodun yazıldığı andan dağıtıma kadar geçen süre
      • Değişiklik başarısızlık oranı: Dağıtımdan sonra hata oluşma oranı
      • MTTR (ortalama toparlanma süresi): Bir sorun oluştuktan sonra toparlanmanın ne kadar sürdüğü

  • 3. Nitel sinyaller toplama

    • Geliştiriciler ve ekipten deneyime dayalı geri bildirimler toplanır:
      • Ekip üyeleri ne zaman verimsizlik hissediyor
      • Hangi araçlar veya prosedürler tekrarlı olarak sorun yaratıyor
      • Hangi faaliyetler en büyük psikolojik yükü oluşturuyor
    • Yöntemler:
      • Anketler, retrospektifler, bire bir görüşmeler vb. kullanılabilir
      • Önceden tanımlanmış ESSP soru listesi de kullanılabilir

  • 4. Temel sorunları tanımlama

    • Toplanan veriler üzerinden engeller (Barrier) tanımlanır
    • Örnekler:
      • "Lead time uzun olduğu için yeni özellik geliştirme gecikiyor"
      • "Build başarısızlıkları sık yaşandığından dağıtım güvenilirliği düşük"
      • "Geliştiriciler sık sık bağlam değiştirmek (context switching) zorunda kalıyor"
    • Sorunlar somut ve gözlemlenebilir bir biçimde ifade edilmelidir

  • 5. Gösterge önceliklendirmesi

    • Tüm göstergeleri aynı anda iyileştirmeye çalışmak yerine, etkisi en büyük olan bir veya iki göstergeye odaklanın
    • Bu öncelik, ileride Step 2 ve Step 3 için iyileştirme denemeleri ve başarı ölçümü kriteri olacaktır
• Step 1'i başarıyla uygulamak için ipuçları
  • 1. Görünüşe değil, kök nedene odaklanın
    • Yalnızca yüzeydeki belirtilere bakarak karar vermeyin; sorunun köküne derinlemesine inmek gerekir
      • Örnek: Yavaşlığın nedeni 'manuel test' gibi görünebilir; ancak asıl neden otomatik testlere duyulan güven eksikliği olabilir
    • Bunun için, yazılım mühendisliğinde sık görülen antipattern örneklerine bakmak faydalıdır
  • 2. Antipattern'lere başvurun
    • Antipattern, sık kullanılan ancak gerçek sorunu çözmeyen, hatta yan etkilere yol açabilen bir yaklaşımı ifade eder
    • GitHub, ekip içinde bulunabilecek antipattern örneklerini ayrı bir kaynak olarak sunduğundan, bunlar öz değerlendirme aracı olarak kullanılabilir
  • 3. Doğru kişileri sürece dahil edin
    • Step 1'in Task 1 bölümünde farklı rollerdeki üyelerden girdi almak önemlidir
      • Örnek: geliştiriciler, tester'lar, operasyon, güvenlik, product manager'lar vb.
    • Bu sayede genel iş akışı çok boyutlu biçimde anlaşılabilir ve belirli bakış açıları gözden kaçmaz
  • 4. Nicel ve nitel verileri dengeli kullanın
    • Yalnızca metriklerle tüm bağlam anlaşılamaz
    • Nicel analize ek olarak, ekip üyelerinin psikolojik, kültürel ve iş birliği sorunlarına dair nitel geri bildirimleri de toplanmalıdır
    • Örnek: düşük ekip morali, iletişim eksikliği, retrospektiflerde dile getirilen memnuniyetsizlikler sayılarla görünmez
  • 5. Çok fazla engel seçmeyin
    • Tüm sorunları aynı anda çözmeye çalışmayın; etkisi en büyük ve en acil engellere odaklanın
    • Başlangıçta çok fazla iyileştirme görevi üstlenmek, uygulama gücünü ve momentumu kaybetme riski taşır
  • 6. Psikolojik güvenliği sağlayın
    • Ekip üyelerinin olumsuz sonuç veya misilleme korkusu olmadan dürüstçe konuşabileceği bir ortam oluşturulmalıdır
    • Bu, gerçek sorunların ortaya çıkarılması için kritik bir koşuldur ve iyileştirme çalışmalarının güvenilirliğini ile etkisini artırır
  • 7. Karşılaştırma değerlendirme için değil, öğrenme içindir
    • Ekipler arası gösterge karşılaştırmaları veya iş akışı farkları, nicel performans değerlendirmesinden çok içgörü üretmek amacıyla kullanılmalıdır
    • Her ekibin durumu, hedefleri, teknoloji yığını ve kısıtları farklı olduğundan, basit karşılaştırmalar yanlış anlamalara yol açabilir
    • Bunun yerine, neyin iyi çalıştığını paylaşan ve ders çıkaran bir öğrenme kültürü teşvik edilmelidir

Adım 2: Hedefinize ulaşmak için nelerin yapılması gerektiğini değerlendirin

• Amaç
  • Step 1'de tanımlanan temel problemi (Barrier) çözmek için hangi değişikliklerin hayata geçirilmesi gerektiğini analiz etme aşaması
  • Basitçe bir özellik eklemek veya araç değiştirmekten öte, organizasyonel, teknik ve kültürel düzeydeki kök nedenleri ve çözümleri belirlemek

• 1. Mevcut durumun kök nedenlerini analiz etme

  • Yalnızca "hız yavaş", "memnuniyet düşük" gibi sonuçların ötesine geçip,
    • neden yavaş olduğunu,
    • hangi yapısal ve organizasyonel nedenlerin bulunduğunu,
    • değiştirilebilir olanlarla olmayanları ayırt etmek gerekir
  • Kullanılabilecek araçlar:
    • 5 Whys tekniği
    • Fishbone (neden-sonuç) diyagramı
    • takım retrospektiflerindeki nitel geri bildirimlerin analizi

• 2. Olası çözümler üretme

  • Problem için teknik, kültürel ve süreç odaklı çözümler üzerine beyin fırtınası yapın
  • Örnekler:
    • Teknik: test hızını artırma, CI/CD pipeline'ını iyileştirme
    • Kültürel: code review pratiklerini düzenleme, onboarding'i iyileştirme
    • Süreç: PR boyutuna sınır koyma, merge kriterlerini değiştirme
  • GitHub'un önerdiği yaklaşım:
    • gözleme dayalı çözümler ile insan odaklı iyileştirmeleri bir arada üretmek

• 3. Etki ve risk değerlendirmesi

  • Her çözüm için şu unsurları değerlendirin:
    • Beklenen etki: Hangi iyileştirme metriklerini etkileyebilir
    • Uygulanabilirlik: Takım kaynakları ve gerçekçi uygulama kapasitesi
    • Organizasyonel kabul: Değişime karşı direnç düzeyi
    • Kısa/uzun vadeli etki ayrımı: Sonuç hızlı mı alınır, yoksa kalıcı bir değişim mi sağlar
  • Bunun için Pilot (deneme uygulaması) önerilir
    • Küçük bir takım ölçeğinde deneyip geri bildirim topladıktan sonra genişletilip genişletilmeyeceğine karar verin

• 4. Öncelik belirleme ve iletişim

  • Birden fazla çözüm arasından şu ölçütlere göre önceliklendirme yapın:
    • en büyük etkiyi yaratabilecek olan
    • en uygulanabilir olan
    • en acil sorun noktasını çözen
  • Bu kararın takım üyeleriyle paylaşılması ve uzlaşma sağlanması gerekir; ayrıca
    • bunu OKR veya iyileştirme hedefi biçiminde açıkça tanımlamak faydalıdır
• Step 2'yi başarıyla yürütmek için ipuçları
  • 1. Uzun vadeli sürdürülebilirliği mutlaka dikkate alın
    • Yalnızca kısa vadeli sonuçlara odaklanmak, uzun vadede sorun yaratabilir
      • Örneğin: yeni bir aracın devreye alınması hızı hemen artırabilir; ancak eğitim, destek ve değişim yönetimi eşlik etmezse hata ve karmaşaya yol açabilir
    • Bu nedenle her iyileştirme girişimi, bakım ve yaygınlaştırılabilirliği de hesaba katan bir strateji olmalıdır
  • 2. Alanlar (zone'lar) arasındaki trade-off'ları dikkate alın
    • Bir alanda (ör. hız) yapılan iyileştirmenin başka bir alanı (ör. geliştirici memnuniyeti, kalite) feda etmemesine dikkat edin
      • Örneğin: review kriterlerini gevşetmek hızı artırabilir ama kod kalitesini veya geliştirici yorgunluğunu kötüleştirebilir
    • Her zaman etki alanının birden fazla alana yayıldığını göz önünde bulunduran dengeli bir yaklaşım gerekir
  • 3. Takımı en baştan sürece dahil edin
    • Takımın doğrudan katıldığı ve birlikte oluşturduğu değişimlerin başarı ihtimali daha yüksektir
    • Değişimin bottom-up şekilde ilerleyebilmesi için ekip üyelerinin görüşlerini toplayın
    • Tek taraflı, emir-komuta tarzı top-down değişiklikler direnç ve ilgisizlik yaratabilir
  • 4. Başarı metriklerini net biçimde tanımlayın
    • Değişiklik uygulanmadan önce neyin başarı sayılacağı konusunda uzlaşılmalıdır
    • Örneğin: hedef “deployment süresini kısaltmak” ise,
      • gecikmeli gösterge: gerçek deployment süresinde azalma
      • öncü gösterge: PR bekleme süresinde azalma, geliştirici anketlerinde 'PR hızında iyileşme hissediyorum' yanıtlarının artması
    • Öncü göstergeleri (Leading Indicator) ve gecikmeli göstergeleri (Lagging Indicator) birlikte tanımlamak idealdir
  • 5. Mükemmel plandan ziyade hızlı deneyleri hedefleyin
    • Küçük değişiklikleri bile hızlıca deneyip geri bildirimle iyileştiren yinelemeli yaklaşım etkilidir
      • Başlangıçta eksik bir deneme olsa bile, küçük ölçekte test edin ve etkinliği kanıtlanırsa genişletin
    • Bu yaklaşım, başarısızlık olasılığını düşürürken takımın değişime karşı çevikliğini ve uyum yeteneğini güçlendirmede avantaj sağlar
  • 6. Önce az çabayla büyük etki yaratacak değişiklikleri deneyin
    • Değişim kalemleri çok ve karmaşıksa, önce “yüksek etki-düşük maliyet” alanındaki iyileştirmeleri seçin
    • Örneğin: basit bir review kılavuzu eklemek, gereksiz bildirimleri kaldırmak gibi adımlar hızlı uygulanabilirken memnuniyet üzerinde büyük etki yaratabilir
    • Erken başarı deneyimi, takıma özgüven verir ve daha zor problemlere ilerlemek için itici güç sağlar

Adım 3: Değişikliklerinizi uygulayın, sonuçları izleyin ve ayarlayın

• Step 2’de çıkarılan iyileştirme girişimlerinin (Intervention) kurum içinde gerçekten uygulanması,
  sonuçlarının ölçülmesi ve gerektiğinde ayarlanması veya yinelemeli olarak iyileştirilmesi yoluyla sürekli mühendislik başarısının hedeflendiği aşama

• 1. Uygulama (Implement the change)

  • Uygulamadan önce aşağıdakiler netleştirilmelidir:
    • Hangi değişiklik yapılacak?
    • Sorumluluğu kim üstlenecek?
    • Hangi metriklere göre değerlendirilecek?
    • Ölçüm hangi tarihler arasında yapılacak?
  • Uygulama sırasında dikkat edilmesi gerekenler:
    • Sorumlu atama: sahipliğin netleştirilmesi
    • Takım onboarding’i ve eğitim: değişikliğin neden gerekli olduğu ve neyin değişeceği tüm ekip üyeleri tarafından anlaşılmalıdır
    • Değişikliğin dokümante edilmesi: kayıt bırakılarak gelecekteki retrospektifler ve yinelemelerde başvuru sağlanabilir
  • Uygulama örnekleri:
    • CI/CD hızını artırmak için build cache stratejisinin değiştirilmesi
    • Kod inceleme politikasının değiştirilmesi (ör. 1 gün içinde yanıt kuralının getirilmesi)

• 2. İzleme (Monitor the change)

  • İyileştirme uygulandıktan sonra, önceden belirlenen metriklerle etkinin takip edilmesi
    • Lead time’ın kısalıp kısalmadığı
    • Başarısızlık oranının azalıp azalmadığı
    • Geliştirici memnuniyetinin artıp artmadığı vb.
  • Araçlar:
    • GitHub Insights, Copilot Telemetry, kurum içi BI sistemleri
    • Haftalık/aylık rapor panoları
    • Geliştirici anketleri veya retrospektif geri bildirimleri
  • Önemli noktalar:
    • Baseline (başlangıç seviyesi) ile karşılaştırma yapılabilmelidir
    • Tek bir sayı yerine trendi (eğilimi) görmek önemlidir

• 3. Geri bildirim toplama (Collect feedback)

  • Nicel metriklerin yanı sıra, değişikliğin geliştirici açısından gerçekten faydalı olup olmadığına dair geri bildirim toplanması gerekir
    • Retrospektifler, anonim anketler, 1:1 görüşmeler vb. kullanılabilir
    • İyileştirmenin ne kadar “hissedildiği” ve tersine yorgunluk yaratan bir değişim olup olmadığı kontrol edilmelidir
  • Kurumsal uzlaşı olmadan aceleyle hayata geçirilen değişiklikler direnç ve tepkiye yol açabilir

• 4. Ayarlama veya yineleme (Adjust as needed)

  • İyileştirme girişiminin sonucu beklentileri karşılamazsa veya yan etkiler oluşursa, şu şekilde hareket edilebilir:
    • Değişiklik geri alınır veya tamamlanır
    • Yalnızca bazı unsurlar korunur ve kapsam daraltılır
    • Daha geniş bir alana yaygınlaştırılır
  • Değişikliğin başarı ya da başarısızlığından bağımsız olarak her zaman şunlar öğrenilmelidir:
    • Hangi unsurlar etkiliydi?
    • Hangi noktalar engelleyici oldu?
    • Bir dahaki sefere neyi değiştirmeliyiz?
• Step 3’ü başarıyla yürütmek için ipuçları
  • 1.Anında mükemmellik beklemeyin
    • Her değişiklik hemen gözle görülür bir iyileşme yaratmayabilir
      • Etkinin ortaya çıkması zaman alabilir
      • Takımın da değişime uyum sağlama sürecine ihtiyacı olduğundan sabır ve sürekli gözlem önemlidir
    • Başlangıçta anket gibi nitel geri bildirim araçlarını kullanarak değişikliğin nasıl hissedildiğini anlamak faydalıdır
  • 2.Değişimi sürekli yineleyin ve iyileştirin
    • Bir kez başarılı oldu diye olduğu gibi korumak yerine, değişim de sürekli evrilmeli ve ayarlanmalıdır
    • Yeni sorunlar ya da dış koşullardaki değişiklikler nedeniyle mevcut iyileştirme önerilerinin de yeniden gözden geçirilmesi gerekebilir
    • Ekibin bunu düzenli bir faaliyet olarak görmesi ve iyileştirme döngüsünü sürdürmesi için teşvik edilmesi gerekir
  • 3.İstenmeyen yan etkilere dikkat edin
    • Bazı değişiklikler başka alanlarda beklenmedik sürtüşmelere neden olabilir
      • Örn. dağıtım hızının artması olumlu bir değişimdir, ancak kalite doğrulaması zayıfsa bug sayısında artışa yol açabilir
    • Yalnızca metriklere değil, iş akışının genelindeki değişimlere de bakılmalı; anormal işaretler ortaya çıktığında hemen müdahale edilmelidir
  • 4.Psikolojik güvenlik durumunu sürekli kontrol edin
    • Değişim sonrasında da ekibin sorunları özgürce dile getirebildiği bir ortamın korunması gerekir
    • “Dile getirilmeyen sorunların” birikmemesi için ekip üyelerinin dürüst geri bildirim verebildiği bir atmosferin oluşturulması gerekir
    • Değişen süreçlere yönelik memnuniyetsizlik, aşırı iş yükü artışı, beklenmedik stres vb.
  • 5.Uzun vadeli etkiyi sürekli değerlendirin
    • Önemli olan kısa vadeli sonuçlar değil, sürdürülebilir performans ve ekip moralindeki artıştır
    • Zaman içinde:
      • Değişikliğin kalıcı hale gelip gelmediği
      • Yeni yan etkilerin veya sorunların ortaya çıkıp çıkmadığı
      • Performansın korunup korunmadığı veya gerileyip gerilemediği sürekli kontrol edilmelidir
  • 6.Geri bildirimi bir öğrenme fırsatı olarak kullanın
    • Başarısız değişiklikler bile değerli bir öğrenme varlığıdır
    • Neyin yanlış gittiği veri ve geri bildirim temelinde analiz edilmeli ve bir sonraki denemeye yansıtılmalıdır
    • Ekip içinde de başarısızlığın bir öğrenme fırsatı olarak görülmesini teşvik eden bir kültür önemlidir

Adımların ötesinde: Rehberi sizin için çalışır hale getirin

• Özelleştirme

  • Kurumun özelliklerine göre ölçülecek metriklerin ve yöntemlerin (telemetri vs anket) seçilmesi gerekir
  • Ölçümü kendi başına amaç haline getirmeden, onu somut iyileştirme için bir araç olarak kullanmak gerekir

• Değişim yönetimi

  • ADKAR, Kotter modeli gibi değişim yönetimi çerçevelerinden yararlanarak kurumun değişime iyi uyum sağlamasına yardımcı olmak önemlidir

• Büyüme zihniyeti

  • Her girişimi bir öğrenme fırsatı olarak görmek ve başarısızlığı kabul eden bir tutum benimsemek, sürekli iyileştirmenin anahtarıdır

• Oyunlaştırma

  • Motivasyona dayalı ödül tasarımı olumlu etki yaratabilir; ancak yanlış tasarlanırsa kalite düşüşü veya dengesizliklere yol açabilir

GitHub Engineering System Success Playbook’a alternatifler

• Duruma göre ESSP yerine basit özellik kullanım odaklı analizler veya tekil araçlara dayalı iyileştirme stratejileri de uygulanabilir
• Önemli olan, ekibe ve kuruma uygun gerçekçi bir yaklaşım ile sürekli iyileştirme çabasıdır