Microsoft AZ-400: Çevik Planlama ve İş Yönetimi — Çalışma kılavuzu

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Şunun bir parçası: Microsoft DevOps Engineer Expert AZ-400 — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Microsoft sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Genel Bakış

Azure DevOps’ta çevik planlama ve iş yönetimi; net bir veri modeli, disiplinli akış ve yineleme pratikleri ve ekipler arası görünürlük üzerine kuruludur. Azure Boards, sağlam bir iş öğesi türleri hiyerarşisi ve ekip başına esnek yapılandırmalar sunarken, GitHub Projects ise Issue’lar ve Pull Request’ler ile sıkı bir şekilde entegre edilmiş, otomasyon odaklı modern bir planlama imkanı sağlar. Etkin bir benimseme; katı tanımlara (Bitti Tanımı, kabul kriterleri), tutarlı tahminlemeye (hikaye puanları ve göreceli boyutlandırma) ve eyleme dönüştürülebilir içgörülere (sorgular, teslimat planları ve DORA dahil metrikler) bağlıdır. Aşağıdaki bölümlerde, bu pratiklerin büyük ölçekte nasıl tasarlanacağı, uygulanacağı ve işletileceği ayrıntılı olarak açıklanmaktadır.

Azure Boards Veri Modeli, Süreç Şablonları ve Ekip Yapılandırması

İş öğesi türleri ve hiyerarşisi, planlamanın bel kemiğini oluşturur. Varsayılan Agile sürecinde portföy hiyerarşisi Epic > Feature > User Story şeklindedir; Task ve Bug ise yürütme seviyesindeki öğelerdir. Alt öğe bağlantıları dekompozisyonu (User Story → Task) yakalar ve Bug’lar, User Story’ler ile aynı backlog seviyesinde yönetilebilir veya ekip politikasına göre bağımsız olarak önceliklendirilebilir. Bağlantı türleri çok önemlidir:

• Parent/Child: Dekompozisyon hiyerarşisini yakalar ve ilerleme ile eforun toplanarak yukarı yansıtılmasını sağlar.
• Predecessor/Successor: İş öğeleri arasındaki zamanlama ve bağımlılık ilişkilerini ifade eder; bunlar Teslimat Planları’nda (Delivery Plans) bağımlılık çizgileri olarak görünür.
• Related/Duplicate/Blocked by: Hiyerarşik olmayan ilişkileri ve engelleri modeller.
• Artifact links: İş öğelerini koda (commit’ler, branch’ler, PR’lar), build’lere ve release’lere bağlayarak uçtan uca izlenebilirlik sağlar.

Azure DevOps süreç şablonları durumları, alanları ve WIT (iş öğesi türü) adlandırmasını tanımlar:

• Agile: Gereksinim seviyesindeki öğe User Story’dir; hızlı hareket eden ekipler genellikle bunu seçer.
• Scrum: Gereksinim seviyesindeki öğe Product Backlog Item (PBI)‘dır; sprint’ler ve Scrum artifact’leri birinci sınıftır ve Bug’lar PBI’lar gibi davranacak şekilde yapılandırılabilir.
• CMMI: Gereksinim seviyesindeki öğe Requirement’tır ve Change Request, Risk ve Review için WIT’ler içerir—riskleri ve resmi gözden geçirmeleri izlemeniz gerektiğinde bunu seçin.
• Özel (Kalıtımsal) süreçler: Azure DevOps Services’te, hizmet uyumluluğunu korurken özel WIT’ler, durumlar, kurallar ve alanlar eklemek için Kalıtım (Inheritance) yoluyla bir sistem sürecini genişletin. Özel bir WIT’i doğru backlog seviyesine yerleştirmek için kategorileri kullanın. Raporlamayı bozan aşırı özelleştirmeden kaçının; Story Points ve Remaining Work gibi alanları standartlaştırın.

Ekipler, aşağıdaki yollarla yapılandırılan hafif bölümlerdir:

• Area paths: Kapsam sahipliğini ve backlog filtrelemeyi belirler; ekipler “kendi” işlerini tanımlamak için bir veya daha fazla alan yolu seçer (ve isteğe bağlı olarak alt alanları dahil eder).
• Iteration paths: Sürüm döngüsünü ve sprint’leri temsil eder; bir ekip planlama için varsayılan ve mevcut yinelemeleri seçer.
• Team backlogs and boards: Her ekip, diğer ekipleri etkilemeden hangi portföy seviyelerinin (Epic, Feature) gösterileceğini, kart stillerini ve ekip başına sütun eşlemelerini seçer.
• Team dashboards: Velocity, Burndown/Burnup, Kümülatif Akış Diyagramı (CFD), Lead/Cycle Time grafikleri ve özel Analiz görünümleri için widget’lar kullanarak paylaşılan görünürlüğü düzenler.

Kanban ve Yönetişim ile Akış Tabanlı Teslimat

Azure Boards’daki Kanban, taahhütten tamamlanmaya kadar olan kesintisiz akışı modeller. Sütunları iş akışı durumlarıyla eşleşecek şekilde yapılandırın ve verim muhasebesini iyileştirmek ve gizli kuyrukları azaltmak için isteğe bağlı olarak kritik durumları Yapılıyor/Bitti (Doing/Done) alt sütunlarına bölün. Sütun ve kulvar (swimlane) başına açık WIP (Devam Eden İş) limitleri belirleyin; bunları operasyonel olarak uygulayın—bir limitin aşılması, sessiz bir backlog büyümesi yerine bir iyileştirme konuşmasını tetikler. Yüksek öncelikli öğeleri görsel olarak ayırmak ve o kulvar için daha sıkı WIP belirlemek amacıyla özel kulvarlar (örneğin, Hızlandır/Expedite) kullanın.

Bitti Tanımı (Definition of Done - DoD), kaliteyi ve öngörülebilirliği güvence altına alır; bunu pano politikaları, belirli geçişlerde zorunlu alanlar veya kontrol listeleri ve kabul testi bağlantısı olarak kodlayın. Örneğin, Bitti (Done) durumuna geçmeden önce başarılı bir Test Case’e bir Test Eden (Tested By) bağlantısı zorunlu kılın ve Yayınlandı (Released) durumuna geçerken dağıtım doğrulama adımlarını yakalayın.

Akış sağlığını yönetmek için analitikleri kullanın:

• Cumulative Flow Diagram, WIP dengesini doğrular ve bantlar genişlediğinde darboğazları tespit eder.
• Lead Time, oluşturulmadan tamamlanmaya kadar geçen süreyi ölçer; Cycle Time ise Aktif (Active) duruma geçişten tamamlanmaya kadar geçen süreye odaklanır. Cycle Time grafik widget’ı, bir iş öğesi Aktif duruma geçtikten sonra geçen süreyi raporlayarak darboğaz analiziyle uyum sağlar.
• Throughput grafikleri, zaman periyodu başına tamamlanan öğeleri izler; istikrarı ve eğilimi takip edin.

İterasyon Planlaması, Backlog İyileştirmesi ve Velocity’ye Dayalı Tahminleme

Sprint planlaması, önceliği zamanla sınırlı (timeboxed) bir taahhüde dönüştürür. Sprint backlog’u, iterasyona çekilen PBI’ları veya User Story’leri listeler. Bunlar, saat cinsinden Remaining Work (Kalan İş) içeren Task’lere (Görevlere) ayrıştırılır. Kişilerin uygunluğunu modellemek için Sprint Capacity’yi (Sprint Kapasitesi) kullanın:

• Aktiviteye (Development, Testing, UX) göre kişi başı günlük saat cinsinden kapasite.
• Tatilleri ve izinleri yansıtmak için bireysel ve takım izin günleri.
• Görevleri aktivitelerle ilişkilendirerek ve kapasiteyi planlanan işle karşılaştırarak aktivite düzeyinde yük dengeleme.

Velocity, sprint başına tamamlanan story point’leri özetler. İstikrarlı bir bant oluşturmak için Velocity grafiğini kullanın; “puan enflasyonundan” (point inflation) kaçının. Product backlog’larında, takımın geçmiş ortalama velocity’sine (son birkaç sprint’e dayalı olarak) ve iterasyon süresine göre backlog’u eritmek (burn down) için kaç tane gelecek iterasyonun gerekeceğini tahmin etmek üzere Forecasting’i (Tahminleme) etkinleştirin. Kısmen tamamlanmış işleri hariç tutarak ve katı bir DoD (Definition of Done) uygulayarak tahminlemenin dürüst kalmasını sağlayın.

Backlog iyileştirmesi (refinement), netliği ve göreceli boyutlandırmayı zorunlu kılar:

• Acceptance criteria: iş öğesinin Acceptance Criteria alanına net, test edilebilir ifadeler kaydedin; belirsizliği azaltmak ve test tasarımını hızlandırmak için Given-When-Then formatını tercih edin.
• Story points: gereksinim düzeyinde göreceli karmaşıklığı ve belirsizliği tahmin edin; puanları saate dönüştürmeyin—görevler (tasks) Remaining Work taşır.
• Göreceli tahminleme (Planning Poker): hızla fikir birliğine varmak için paylaşılan bir temel (baseline) ve bir dizi (Fibonacci veya değiştirilmiş Fibonacci) kullanın. Takımlar, Azure Boards içinde Planning Poker yürütmek için Marketplace eklentilerini kullanabilir ve tutarlı raporlama için tahminleri Story Points/Effort alanlarına yazabilir.

Bug’lar (hatalar) önceliklendirilmeli (triage) ve ya gereksinimler gibi ele alınmalı (puanla tahmin edilip backlog’da planlanmalı) ya da sprint içindeki görevler (tasks) olarak yönetilmelidir; velocity’yi tutarlı tutmak için takım başına tek bir politika seçin.

Ekipler Arası Planlama, Sorgular, Raporlama, GitHub Projects ve DevOps Metrikleri

Büyük programlar, ekipler ve repolar arasında görünürlük gerektirir:

• Delivery Plans: alan/iterasyon yollarına göre filtrelenmiş çoklu ekip zaman çizelgeleri oluşturun. Bağımlılık çizgileri (Predecessor/Successor bağlantılarından) ve kilometre taşları (sürüm tarihleri, harici taahhütler) için işaretçilerle işi iterasyona göre görselleştirin. Feature ve Epic’lerdeki toplu ilerlemeyi gösterin ve yönetişim incelemeleri için özel alanları (ör. Risk) ortaya çıkarın.
• Sorgular ve raporlama: “bu filtrelere hangi öğeler uyuyor” sorusunu yanıtlamak için Düz liste sorguları, toplu gösterimlerle hiyerarşide gezinmek için İş öğeleri ağacı ve tek bir bağlantı atlamasını (ör. Feature → Story’ler veya Bug → commit’ler) analiz etmek için Doğrudan bağlantı sorguları oluşturun. Sorguları kaydedin ve paylaşın, grafikler (pasta, çubuk, trend) ekleyin ve bunları panolara sabitleyin. Analitik düzeyinde raporlama için, portföy burndown, bağımlılık risk ısı haritaları ve DORA görselleştirmeleri üretmek üzere Azure DevOps Analytics hizmetini ve Power BI ile OData’yı kullanın. Yerleşik raporlar arasında Velocity, Burndown/Burnup, CFD, Lead Time, Cycle Time ve Sprint Capacity kullanımı bulunur.

GitHub Projects, planlamayı Issue’lar ve PR’lar ile entegre eder:

• Proje panoları: organizasyon veya repo kapsamında Kanban veya tablo görünümleri oluşturun, özel alanlar (Status, Iteration, Priority) tanımlayın ve ekibe göre filtreleyin.
• Otomasyon kuralları: bir Issue veya PR açıldığında, birleştirildiğinde veya kapatıldığında Status’u ayarlamak; tamamlanmış öğeleri otomatik olarak arşivlemek; alan değişikliklerine göre atama veya etiketleme yapmak; ve öğeleri görünümler arasında taşımak için yerleşik iş akışlarını yapılandırın. Gelişmiş otomasyonlar için GitHub Actions ile birleştirin.
• Issue ve PR entegrasyonu: Issue’lar ve PR’lar, Projects’te birinci sınıf öğelerdir. Issue’ları bağlamak ve otomatik olarak kapatmak için PR açıklamalarında anahtar kelimeler (Fixes #123) kullanın. Status ve gözden geçirenler panoda görünür, bu da koddan plana izlenebilirlik sağlar.

DevOps metrikleri kodu, dağıtımı ve sonuçları birbirine bağlamalıdır:

• DORA metrikleri:
  • Deployment frequency (Dağıtım sıklığı): günde/haftada yapılan production dağıtımlarının sayısını ölçün; kaynak olarak pipeline sürüm olaylarını kullanın.
  • Lead time for changes (Değişiklikler için teslim süresi): kod commit’inden (veya PR birleştirmesinden) production dağıtımına kadar olan süreyi ölçün; pipeline’ların dağıtım zaman damgaları yaydığından ve bunları commit’lerle ilişkilendirdiğinden emin olun.
  • Change failure rate (Değişiklik hata oranı): müşteri etkileyen bir olaya veya geri almaya neden olan production dağıtımlarının oranı; olay yönetimi etiketleri ve pipeline sonuçları ile entegre edin.
  • Mean time to restore (MTTR - Ortalama kurtarma süresi): olayın başlangıcından hizmetin yeniden sağlanmasına kadar geçen süre; izleme uyarılarından ve olay kapanış zamanlarından yola çıkın. Planlamanın mı yoksa teslimatın mı kısıt olduğunu tespit etmek için DORA’yı Pano analitiği (Lead/Cycle time) ile ilişkilendirin. Sürekli iyileştirme için her iki metrik setini de aynı kitleye sunmak üzere panoları kullanın.

Pratik Problem Senaryosu

Microsoft’un Reklamcılık bölümü, paylaşılan bir kampanya yönetimi platformu sunan sekiz çapraz fonksiyonlu ekibi hizalamaktadır. Kod tabanı GitHub’da bulunmaktadır; organizasyonun güvenilir üç aylık taahhütlere, net bağımlılık görünürlüğüne ve araç karmaşası eklemeden eyleme geçirilebilir akış ve DORA metriklerine ihtiyacı vardır.

1. Azure DevOps Agile sürecini seçin ve ekipleri yapılandırın

• Neden: Agile, basitliği portföy toplu gösterimleri ile dengeleyen Epic > Feature > User Story hiyerarşisini sağlar. Her biri kendi alan yoluna ve mevcut/gelecek iterasyon yollarına sahip sekiz ekip oluşturun; bu, organizasyon çapında raporlamayı korurken panolarda ve panolarda özerklik sağlar.

2. Kanban yönetişimini ve pano yapılandırmasını tanımlayın

• Neden: Sprint’ler arasındaki sürekli akış, bekleme süresini azaltır. In Progress ve Code Review için Doing/Done ayrımlarıyla durumlara eşlenmiş sütunları yapılandırın. Sütun başına WIP limitleri belirleyin ve daha düşük bir WIP ile bir Expedite (Hızlandırma) kulvarı ekleyin. Done’a geçişi kontrol etmek için Definition of Done’ı (birim testleri geçer, PR onaylanır, dağıtım doğrulama kontrol listesi tamamlanır) belirten pano politikaları ekleyin.

3. Backlog iyileştirme ve tahmin disiplinini uygulayın

• Neden: Öngörülebilir taahhütler, tutarlı boyutlandırma ve netlik gerektirir. User Story’lerde Given-When-Then kullanarak kabul kriterlerini yakalayın. Bir Azure Boards eklentisi kullanarak Planning Poker (Fibonacci 1–13) aracılığıyla Story Point’leri standartlaştırın ve Sprint Capacity’yi desteklemek için görev tahminlerini Remaining Work saatlerinde tutun.

4. Kapasite ve velocity tabanlı tahminle sprint’leri planlayın

• Neden: Kapasite planlaması aşırı taahhüdü azaltır. Aktiviteye ve izin günlerine göre bireysel kapasiteleri girin. Gerçekçi bir sprint hedefi belirlemek için son altı sprint’in Velocity grafiğini kullanın. Üç aylık Epic hedeflerine ulaşmak için kaç sprint gerektiğini projelendirmek ve paydaş beklentilerini hizalamak için backlog Forecasting’i etkinleştirin.

5. Ekipler arası görünürlük için Delivery Plans oluşturun

• Neden: Bağımlılıklar ve kilometre taşları tek bir zaman çizelgesinde görünür olmalıdır. Sekiz ekibin ve portföy seviyelerinin tamamını içeren bir Delivery Plan oluşturun. Üç aylık sürüm tarihleri ve pazar etkinlikleri için kilometre taşı işaretçileri ekleyin. Bağımlılık çizgilerini göstermek ve öğelerin iterasyonlar arasında uzandığı yerlerdeki riski ortaya çıkarmak için Predecessor/Successor bağlantılarını kullanın.

6. Repoya odaklı yürütme görünümleri için GitHub Projects’i entegre edin

• Neden: Geliştiriciler GitHub’da yaşar; Projects, yürütme bağlamını koda yakın tutar. Pano ve tablo görünümleriyle organizasyon düzeyinde bir GitHub Project oluşturun. PR açıldığında Status’u In Progress’e, PR birleştirildiğinde Done’a ayarlamak ve kapatılan Issue’ları otomatik olarak arşivlemek için otomasyon kuralları ekleyin. Bağlantılı Issue’ları kapatmak ve durumu panoya yansıtmak için PR’larda “Fixes #<id>” kullanın.

7. İzlenebilirlik için kodu ve işi bağlayın

• Neden: Uçtan uca izlenebilirlik, doğru raporlama ve denetimleri mümkün kılar. Commit mesajlarında ve PR açıklamalarında Azure Boards iş öğesi ID’sine referans vermeyi zorunlu kılın; Delivery Plans ve analitiklerin kod aktivitesinden ilerlemeyi toplayabilmesi için iş öğelerinde artifact bağlantıları kullanın.

8. Akış ve DORA metriklerini panolarda gösterin

• Neden: Paylaşılan, otomatikleştirilmiş metrikler iyileştirmeyi teşvik eder. Ekip panolarında, akışı yönetmek için CFD, Lead Time ve Cycle Time grafiklerini sabitleyin. Bir program panosunda, Velocity, Delivery Plan özetini ve DORA metriklerini yüzeye çıkarın: production aşamalarından gelen pipeline dağıtım olaylarını kullanarak dağıtım sıklığını ve teslim süresini hesaplayın; olayları etiketleyerek ve dağıtımlarla ilişkilendirerek değişiklik hata oranını ve MTTR’yi türetin. Bu birleşik görünüm, kısıtların planlamada mı (pano lead/cycle time) yoksa teslimatta mı (DORA) olduğunu vurgular.

Bu yaklaşım, ekip özerkliği (ekibe özel panolar, kapasite ve panolar) ile program yönetişimini (Delivery Plans, bağımlılıklar ve kilometre taşları) dengeler. Azure Boards hiyerarşik planlama ve analitik sağlarken, GitHub Projects Issue’lar ve PR’lara bağlı otomasyon ile günlük geliştirici takibini kolaylaştırır ve DORA metrikleri, güvenilir, veriye dayalı taahhütler için planlamayı operasyonel sonuçlarla birleştirir.

← Paket Yönetimi ve Yapıt Yönetimi · Tüm alanlar

Bu soruları çözün → · ExamRoll.io’da süreli pratik →

Microsoft'a göz atın →