[![image](https://img.shields.io/discord/772774097734074388?label=Discord&logo=discord)](https://discord.com/servers/software-engineering-courses-secourses-772774097734074388) [![Hits](https://hits.sh/github.com/FurkanGozukara/Stable-Diffusion/blob/main/Tutorials/Mühendislik-Uygulamalarında-Profesyonel-Yetkinlikler-ve-Standartlar.md.svg?style=plastic&label=Hits%20Since%2025.08.27&labelColor=007ec6&logo=SECourses)](https://hits.sh/github.com/FurkanGozukara/Stable-Diffusion/blob/main/Tutorials/Mühendislik-Uygulamalarında-Profesyonel-Yetkinlikler-ve-Standartlar.md)
[![Patreon](https://img.shields.io/badge/Patreon-Support%20Me-F2EB0E?style=for-the-badge&logo=patreon)](https://www.patreon.com/c/SECourses) [![BuyMeACoffee](https://img.shields.io/badge/Buy%20Me%20a%20Coffee-ffdd00?style=for-the-badge&logo=buy-me-a-coffee&logoColor=black)](https://www.buymeacoffee.com/DrFurkan) [![Furkan Gözükara Medium](https://img.shields.io/badge/Medium-Follow%20Me-800080?style=for-the-badge&logo=medium&logoColor=white)](https://medium.com/@furkangozukara) [![Codio](https://img.shields.io/static/v1?style=for-the-badge&message=Articles&color=4574E0&logo=Codio&logoColor=FFFFFF&label=CivitAI)](https://civitai.com/user/SECourses/articles) [![Furkan Gözükara Medium](https://img.shields.io/badge/DeviantArt-Follow%20Me-990000?style=for-the-badge&logo=deviantart&logoColor=white)](https://www.deviantart.com/monstermmorpg)

[![YouTube Channel](https://img.shields.io/badge/YouTube-SECourses-C50C0C?style=for-the-badge&logo=youtube)](https://www.youtube.com/SECourses)  [![Furkan Gözükara LinkedIn](https://img.shields.io/badge/LinkedIn-Follow%20Me-0077B5?style=for-the-badge&logo=linkedin&logoColor=white)](https://www.linkedin.com/in/furkangozukara/)   [![Udemy](https://img.shields.io/static/v1?style=for-the-badge&message=Stable%20Diffusion%20Course&color=A435F0&logo=Udemy&logoColor=FFFFFF&label=Udemy)](https://www.udemy.com/course/stable-diffusion-dreambooth-lora-zero-to-hero/?referralCode=E327407C9BDF0CEA8156) [![Twitter Follow Furkan Gözükara](https://img.shields.io/badge/Twitter-Follow%20Me-1DA1F2?style=for-the-badge&logo=twitter&logoColor=white)](https://twitter.com/GozukaraFurkan)

# Mühendislik Uygulamalarında Profesyonel Yetkinlikler ve Standartlar

## Bölüm 0: Giriş ve Yol Haritası

### 0.1. Derse Hoş Geldiniz!

Merhaba değerli mühendis adayı,

Bu eğitim materyali, modern mühendislik pratiğinin temel taşlarından olan **Proje Yönetimi, Risk Yönetimi ve Değişiklik Yönetimi** konularında size sağlam bir temel kazandırmak amacıyla tasarlanmıştır. Bu dersi bir hoca anlatmayacak; bu materyal, sizin kendi hızınızda, kendi kendinize çalışarak bu önemli yetkinlikleri kazanmanız için eksiksiz bir rehber niteliğindedir.

Mühendislik sadece teknik problem çözmekten ibaret değildir. Başarılı bir mühendis, aynı zamanda projeleri zamanında ve bütçesinde tamamlayan, olası riskleri öngörüp yöneten ve proje sürecindeki değişikliklere kontrollü bir şekilde adapte olabilen bir profesyoneldir. Bu materyal, sizi bu profesyonel dünyaya hazırlamayı hedeflemektedir.

**Tahmini Çalışma Süresi:** Bu materyali baştan sona dikkatlice okumak, örnekleri anlamak ve kendini değerlendirme sorularını yanıtlamak yaklaşık **8 saat** sürecektir.

**Öğrenim Hedefleri:**
Bu 8 saatlik çalışmanın sonunda aşağıdaki yetkinliklere sahip olacaksınız:
*   Bir projenin ne olduğunu, özelliklerini ve operasyonel işlerden farkını açıklayabileceksiniz.
*   Proje yönetimi yaşam döngüsünü (Başlangıç, Planlama, Yürütme, İzleme & Kontrol, Kapanış) ve her aşamadaki temel aktiviteleri tanımlayabileceksiniz.
*   Geleneksel (Şelale) ve Çevik (Agile - Scrum, Kanban) proje yönetimi metodolojilerinin temel prensiplerini, avantajlarını ve hangi durumlarda kullanıldıklarını karşılaştırabileceksiniz.
*   Bir projedeki risk kavramını, risk yönetimi sürecini (tanımlama, analiz, yanıt planlama, izleme) ve temel stratejileri (kaçınma, azaltma, aktarma, kabul etme) açıklayabileceksiniz.
*   Proje değişiklik yönetimi sürecini, "kapsam kayması" (scope creep) tehlikesini ve değişikliklerin kontrollü bir şekilde nasıl yönetileceğini anlatabileceksiniz.
*   Bu üç disiplinin (proje, risk ve değişiklik yönetimi) gerçek bir mühendislik projesinde nasıl bir bütün olarak çalıştığını kavrayacaksınız.

### 0.2. Bu Materyal Nasıl Kullanılır?

Bu döküman, kendi kendine öğrenme için özel olarak tasarlanmıştır. En iyi verimi almak için aşağıdaki adımları izlemenizi öneririz:

1.  **Sırayla İlerleyin:** Konular birbiri üzerine inşa edilmiştir. Lütfen bölümleri atlamadan, sırayla çalışın.
2.  **Not Alın:** Önemli bulduğunuz tanımları, süreçleri ve anahtar kavramları kendi not defterinize yazın. Yazmak, öğrenmeyi pekiştirir.
3.  **Örnekleri Anlayın:** Her bölümde, konuları somutlaştırmak için bolca örnek ve senaryo bulunmaktadır. Bu örneklerin, özellikle "HızlıAl E-Ticaret Uygulaması" senaryosunun, kavramları nasıl hayata geçirdiğini dikkatlice inceleyin.
4.  **Ara Vermeyi Unutmayın:** 8 saatlik çalışma uzun bir süredir. Her bölüm sonunda veya yorulduğunuzu hissettiğinizde 10-15 dakikalık aralar verin.
5.  **Kendinizi Test Edin:** Materyalin sonunda yer alan "Kendini Değerlendirme Soruları" bölümünü, materyale bakmadan cevaplamaya çalışın. Bu, sınav öncesi eksiklerinizi görmenizi sağlayacaktır.

### 0.3. Profesyonel Mühendislikte Standartların Önemi

Neden bu konuları öğreniyoruz? Çünkü mühendislik projeleri karmaşık, maliyetli ve yüksek beklentiler içeren çalışmalardır. Standartlar ve metodolojiler olmadan yürütülen projeler genellikle şu sorunlarla karşılaşır:
*   **Bütçenin aşılması:** Plansız harcamalar ve verimsizlik.
*   **Teslimat tarihlerinin kaçırılması:** Gecikmelerin müşteri memnuniyetsizliğine ve pazar fırsatlarının kaybına yol açması.
*   **Düşük kalite:** İstenen özelliklerin karşılanmaması, hatalı veya kullanışsız ürünler.
*   **Ekip içinde kaos ve motivasyon düşüklüğü:** Belirsizlik, sürekli değişen hedefler ve rol karmaşası.

Bu materyalde öğreneceğiniz proje, risk ve değişiklik yönetimi disiplinleri, bu kaosun önüne geçmek için geliştirilmiş **evrensel standartlardır**. Bu standartları bilmek ve uygulamak, sizi daha değerli, daha güvenilir ve daha başarılı bir mühendis yapacaktır.

---

## Bölüm 1: Proje Yönetimi Temelleri (Tahmini Süre: 3 Saat)

Bu bölümde, proje yönetiminin ne olduğunu, temel kavramlarını, yaşam döngüsünü ve en popüler metodolojileri derinlemesine inceleyeceğiz.

### 1.1. Proje Nedir?

> **Tanım: Proje**, özgün bir ürün, hizmet veya sonuç yaratmak için yürütülen **geçici** bir girişimdir.

Bu tanımın iki kilit kelimesi vardır: **Geçici** ve **Özgün**.

*   **Geçici (Temporary):** Her projenin net bir başlangıç ve bitiş tarihi vardır. Proje hedeflerine ulaşıldığında veya projenin artık gereksiz olduğuna karar verildiğinde sona erer. "Geçici" olması, projenin sonucunun geçici olduğu anlamına gelmez. Örneğin, bir köprü inşaatı projesi biter, ancak köprü kalıcıdır. Bir yazılım projesi biter, ancak yazılım yıllarca kullanılır.

*   **Özgün (Unique):** Her proje, daha önce yapılmamış bir şeyi ortaya çıkarır. Bu, tamamen yeni bir icat olabileceği gibi, mevcut bir ürünün yeni bir versiyonu veya bir şirkette yeni bir sürecin tasarlanması da olabilir. İki proje asla yüzde yüz aynı değildir.

**Proje ve Operasyon Arasındaki Fark**

Bu ayrımı anlamak çok önemlidir.
*   **Operasyonlar**, bir işletmenin sürekliliğini sağlayan, tekrarlayan ve standart işlerdir. Örneğin, bir fabrikanın her gün aynı arabayı üretmesi, bir sunucunun 7/24 çalışır durumda tutulması veya bir çağrı merkezinin sürekli müşteri taleplerini karşılaması operasyonel işlerdir.
*   **Projeler** ise bu operasyonları iyileştirmek, değiştirmek veya yenilerini yaratmak için yapılır.

| Özellik | Proje | Operasyon |
| :--- | :--- | :--- |
| **Süre** | Geçici (Başlangıcı ve Bitişi Var) | Sürekli |
| **Amaç** | Özgün bir ürün/sonuç yaratmak | İşin devamlılığını sağlamak |
| **Sonuç** | Özgün (Unique) | Tekrarlayan (Repetitive) |
| **Örnek (Yazılım)** | Yeni bir mobil bankacılık uygulaması geliştirmek. | Mevcut mobil bankacılık sunucularının bakımını yapmak. |
| **Örnek (İnşaat)** | Yeni bir hastane binası inşa etmek. | Mevcut hastaneyi temizlemek ve işletmek. |

**Bir Bilgisayar Mühendisi Neden Proje Yönetimini Bilmelidir?**

Kariyeriniz boyunca yapacağınız işlerin büyük bir kısmı projelerden oluşacaktır:
*   Yeni bir web sitesi geliştirmek bir projedir.
*   Bir şirketin veri tabanını buluta taşımak bir projedir.
*   Yapay zeka tabanlı bir öneri motoru tasarlamak bir projedir.
*   Bir oyunun yeni bir bölümünü kodlamak bir projedir.

Bu projelerde sadece kod yazan bir geliştirici olsanız bile, projenin genel hedeflerini, zaman çizelgesini ve bütçesini anlamak, sizin daha verimli ve etkili bir ekip üyesi olmanızı sağlar. Kariyerinizde ilerledikçe (takım lideri, teknik müdür, proje yöneticisi), bu yetkinlikler vazgeçilmez hale gelecektir.

### 1.2. Proje Yönetiminin Altın Üçgeni (Proje Kısıtları)

Her proje, birbiriyle sürekli çekişme halinde olan üç temel kısıt tarafından yönetilir. Bunlara **"Demir Üçgen"** veya **"Altın Üçgen"** denir.



1.  **Kapsam (Scope):** Projede **ne** yapılacağını tanımlar. Projenin hedefleri, özellikleri, fonksiyonları ve teslim edilecek tüm işler kapsamın bir parçasıdır. *Örnek: "Müşterilerin ürünleri favorilerine ekleyebileceği bir özellik geliştirmek."*

2.  **Zaman (Time):** Projenin tamamlanması için ayrılan süredir. Proje takvimi, kilometre taşları (milestones) ve son teslim tarihleri bu kısıtı oluşturur. *Örnek: "Favorilere ekleme özelliği 3 hafta içinde canlıya alınmalıdır."*

3.  **Maliyet (Cost):** Projenin bütçesidir. Ekip üyelerinin maaşları, yazılım lisansları, donanım masrafları gibi tüm harcamaları içerir. *Örnek: "Bu özelliğin geliştirilmesi için ayrılan bütçe 20.000 TL'dir."*

**Merkezdeki Unsur: Kalite (Quality)**

Bu üçgenin tam ortasında **Kalite** yer alır. Kalite, projenin ve sonucunun gereksinimleri ne kadar iyi karşıladığıdır.

**Kısıtlar Arasındaki Denge (Trade-offs)**

Bu üçgenin sihri, bir köşesini değiştirdiğinizde diğer köşelerin de etkilenmesidir.
*   **Kapsamı artırmak isterseniz** (örneğin, "Favorilere ekleme özelliğine bir de paylaşma butonu ekleyelim"), bunu aynı zaman ve maliyetle yapamazsınız. Ya **zamanı** uzatmanız ya da **maliyeti** (daha fazla geliştirici işe alarak) artırmanız gerekir. Bunları sabit tutmaya çalışırsanız, **kaliteden** ödün verirsiniz (özellik aceleye gelir, hatalı çalışır).
*   **Zamanı kısaltmak isterseniz** (örneğin, "Bu özellik 3 hafta değil, 1 haftada bitmeli"), ya **kapsamı** daraltmanız (daha az iş yapmak) ya da **maliyeti** artırmanız (daha fazla kişi çalıştırmak) gerekir.
*   **Maliyeti düşürmek isterseniz** (örneğin, "Bütçeyi 10.000 TL'ye çekelim"), ya **kapsamı** küçültmeniz ya da **zamanı** uzatmanız (daha az ve/veya daha ucuz kaynakla daha yavaş çalışmak) gerekir.

> **Pro-Tip:** Başarılı bir proje yöneticisi, bu üç kısıt arasında paydaşların beklentilerini karşılayacak en uygun dengeyi kurabilen kişidir. "Hızlı, ucuz ve kaliteli; üçünden ikisini seçin" sözü bu dengeyi mükemmel bir şekilde özetler.

### 1.3. Proje Yaşam Döngüsü (Project Lifecycle)

Projeler kaotik bir şekilde başlamaz ve bitmez. Genellikle 5 ana faza ayrılan yapısal bir yaşam döngüsünü takip ederler.

#### Faz 1: Başlangıç (Initiation)
Bu faz, projenin resmi olarak tanımlandığı ve yetkilendirildiği aşamadır.
*   **Amaç:** Projenin varoluş nedenini ve ana hedeflerini belirlemek.
*   **Anahtar Aktiviteler:**
    *   İş Gerekçesi (Business Case) hazırlamak: "Bu projeyi neden yapmalıyız? Şirkete ne faydası olacak?"
    *   Fizibilite Çalışması yapmak: Proje teknik, ekonomik ve operasyonel olarak yapılabilir mi?
    *   **Proje Beratı (Project Charter)** oluşturmak: Bu, projenin doğum belgesidir. Projenin adını, amacını, ana hedeflerini, kısıtlarını, varsayımlarını, ana paydaşlarını ve en önemlisi **Proje Yöneticisi**'ni ve yetkilerini tanımlayan resmi bir belgedir.
    *   Ana Paydaşları Belirlemek (Stakeholder Identification): Projeden etkilenecek veya projeyi etkileyebilecek herkes (müşteri, sponsor, kullanıcılar, ekip, yöneticiler vb.).
*   **Faz Sonu Çıktısı:** Onaylanmış bir Proje Beratı.

#### Faz 2: Planlama (Planning)
Bu, projenin "nasıl" yapılacağının detaylı bir şekilde tasarlandığı en kritik fazdır. İyi bir plan, başarının yarısıdır.
*   **Amaç:** Projeyi başarıyla tamamlamak için bir yol haritası oluşturmak.
*   **Anahtar Aktiviteler:**
    *   **Kapsam Planlama:** Projede tam olarak nelerin yapılıp nelerin yapılmayacağını netleştirmek.
    *   **İş Kırılım Yapısı (Work Breakdown Structure - WBS) Oluşturma:** Projenin tüm teslim edilebilir sonuçlarını ve işlerini hiyerarşik bir yapıda küçük, yönetilebilir parçalara ayırmak. Bu, "filin nasıl yeneceğini" gösteren bir haritadır.
    *   **Zaman Çizelgesi (Schedule) Geliştirme:** Her iş paketinin ne kadar süreceğini tahmin etmek, aktiviteleri sıralamak ve Gantt şeması gibi araçlarla projenin takvimini oluşturmak.
    *   **Maliyet ve Bütçe Planlama:** Her aktivitenin maliyetini tahmin etmek ve projenin toplam bütçesini oluşturmak.
    *   **Kalite Planlama:** Kalite standartlarını ve kontrol yöntemlerini belirlemek.
    *   **Kaynak Planlama:** Hangi yeteneklere sahip kaç kişiye, hangi donanım ve yazılımlara ihtiyaç olduğunu belirlemek.
    *   **İletişim Planlama:** Kimin, ne zaman, hangi bilgiye, nasıl ulaşacağını planlamak.
    *   **Risk Yönetimi Planlama:** Potansiyel riskleri nasıl yöneteceğimizi planlamak (Bu konuyu Bölüm 2'de detaylandıracağız).
*   **Faz Sonu Çıktısı:** Kapsamlı bir **Proje Yönetim Planı**.

#### Faz 3: Yürütme (Execution)
Planın hayata geçirildiği, işin fiilen yapıldığı fazdır.
*   **Amaç:** Proje planında tanımlanan işleri tamamlamak.
*   **Anahtar Aktiviteler:**
    *   Proje ekibini yönetmek ve geliştirmek.
    *   Kaynakları (insan, bütçe, ekipman) tahsis etmek ve yönetmek.
    *   İletişim planına göre paydaşları bilgilendirmek.
    *   Proje işlerini (kodlama, tasarım, test vb.) gerçekleştirmek.
*   **Faz Sonu Çıktısı:** Projenin **teslim edilebilir sonuçları** (Deliverables).

#### Faz 4: İzleme ve Kontrol (Monitoring & Controlling)
Bu faz, Yürütme fazı ile paralel ilerler. Projenin plana göre gidip gitmediğini sürekli olarak kontrol eder.
*   **Amaç:** Proje performansını ölçmek, plandan sapmaları tespit etmek ve düzeltici/önleyici aksiyonlar almak.
*   **Anahtar Aktiviteler:**
    *   Performansı İzleme: Zaman, maliyet ve kapsam performansını takip etmek (Örn: "Takvimin gerisinde miyiz? Bütçeyi aşıyor muyuz?").
    *   Kapsam Kontrolü: "Kapsam kaymasını" (scope creep) önlemek.
    *   Değişiklik Taleplerini Yönetme (Bu konuyu Bölüm 3'te detaylandıracağız).
    *   Riskleri İzleme.
    *   Kalite Kontrolü: Yapılan işlerin kalite standartlarına uygunluğunu denetlemek.
*   **Faz Sonu Çıktısı:** Performans raporları, onaylanmış değişiklik talepleri, güncellenmiş proje planları.

#### Faz 5: Kapanış (Closing)
Projenin resmi olarak tamamlandığı ve sonlandırıldığı fazdır.
*   **Amaç:** Projeyi usulüne uygun bir şekilde bitirmek ve tüm süreçleri tamamlamak.
*   **Anahtar Aktiviteler:**
    *   Proje sonuçlarının müşteriye veya sponsora resmi teslimatını yapmak ve onayını almak.
    *   Tüm sözleşmeleri ve idari işlemleri kapatmak.
    *   Ekibi serbest bırakmak.
    *   **Öğrenilmiş Dersler (Lessons Learned)** belgesi hazırlamak: Projede neyin iyi gittiğini, neyin kötü gittiğini ve gelecekteki projelerde nelerin farklı yapılabileceğini dokümante etmek. Bu, kurumsal hafıza için hayati öneme sahiptir.
    *   Proje arşivini oluşturmak ve saklamak.
*   **Faz Sonu Çıktısı:** Proje kapanış raporu, öğrenilmiş dersler, arşivlenmiş proje dosyaları.

### 1.4. Proje Yönetimi Metodolojileri

Proje yaşam döngüsünü takip etmenin farklı yolları vardır. Bunlara metodoloji denir. En yaygın iki yaklaşım Geleneksel (Şelale) ve Çevik (Agile) yaklaşımlardır.

#### Geleneksel Metodoloji: Şelale (Waterfall)

Şelale modeli, adını bir şelalenin basamaklarından aşağı doğru akmasından alır. Her fazın tamamen bitirilip bir sonraki faza geçildiği, **sıralı (sequential)** bir yaklaşımdır.

**Şelale Modelinin Fazları:**
1.  **Gereksinim Analizi:** Tüm gereksinimler en başta toplanır ve dokümante edilir.
2.  **Tasarım:** Yazılımın ve sistemin mimarisi tasarlanır.
3.  **Geliştirme (Kodlama):** Tasarıma dayalı olarak kodlama yapılır.
4.  **Test:** Geliştirilen ürün baştan sona test edilir.
5.  **Dağıtım (Deployment):** Ürün müşteriye teslim edilir.
6.  **Bakım:** Ürünün canlı ortamdaki bakımı yapılır.



**Avantajları:**
*   **Basit ve Anlaşılır:** Yapısı nettir, takip etmesi kolaydır.
*   **İyi Dokümantasyon:** Her fazın sonunda detaylı dokümanlar üretilir.
*   **Disiplinli:** Fazlar arası geçişler katıdır, bu da kontrolü kolaylaştırır.

**Dezavantajları:**
*   **Katı ve Değişime Kapalı:** Projenin başında her şeyin bilinmesi varsayımına dayanır. Eğer projenin ortasında bir gereksinim değişirse, geri dönmek çok zor ve maliyetlidir.
*   **Müşteri Geri Bildirimi Geç Alınır:** Müşteri, bitmiş ürünü projenin en sonunda görür. Bu noktada beğenmezse, her şey için çok geç olabilir.
*   **Yüksek Risk:** Test aşamasına kadar ciddi hatalar fark edilmeyebilir.

**Ne Zaman Kullanılır?**
*   Gereksinimlerin çok net, iyi tanımlanmış ve değişme olasılığının düşük olduğu projelerde.
*   Proje kapsamının sabit olduğu durumlarda.
*   **Örnek:** Bir köprü inşaatı, bir uçağın uçuş kontrol yazılımı (gereksinimler en başta çok katı bir şekilde belirlenir), bir veri merkezi kurulumu.

#### Çevik Metodoloji: Agile

Agile, bir metodolojiden çok, bir **felsefe** ve **zihniyettir**. 2001'de yayınlanan **Çevik Yazılım Geliştirme Manifestosu**'na dayanır. Değişimin kaçınılmaz olduğunu kabul eder ve projeyi küçük, artırımlı parçalar halinde, sürekli müşteri geri bildirimi alarak geliştirmeyi hedefler.

**Çevik Manifesto'nun 4 Temel Değeri:**

> **Süreçler ve araçlardan ziyade bireyler ve etkileşimlere**
> **Kapsamlı dokümantasyondan ziyade çalışan yazılıma**
> **Sözleşme pazarlıklarından ziyade müşteri ile işbirliğine**
> **Bir plana sıkı sıkıya bağlı kalmaktan ziyade değişime yanıt vermeye**
>
> değer veririz.

Bu, sağdaki maddelerin değersiz olduğu anlamına gelmez, sadece soldaki maddelerin **daha değerli** olduğu anlamına gelir.

Agile felsefesini uygulayan birçok çerçeve (framework) vardır. En popüler ikisi Scrum ve Kanban'dır.

##### **Scrum Çerçevesi**

Scrum, karmaşık ürünleri geliştirmek için kullanılan, kuralları basit ama uygulaması zor bir çerçevedir. Projeyi **Sprint** adı verilen kısa zaman dilimlerine (genellikle 1-4 hafta) böler. Her Sprint sonunda, müşteriye sunulabilecek, çalışan bir ürün parçası ("Increment") ortaya çıkarılır.

**Scrum'ın 3 Rolü:**
1.  **Product Owner (Ürün Sahibi):** Projenin "ne" yapılacağından sorumludur. Müşterinin sesidir. Yapılacak işleri önceliklendirdiği **Product Backlog**'u yönetir.
2.  **Scrum Master:** Scrum kurallarının doğru uygulanmasını sağlayan, ekibin önündeki engelleri kaldıran bir hizmetkar liderdir. Proje yöneticisi değildir.
3.  **Development Team (Geliştirme Ekibi):** Ürünü geliştiren, kendi kendini organize eden, 3 ila 9 kişilik bir ekiptir.

**Scrum'ın 5 Olayı (Events):**
1.  **The Sprint:** Her şeyin içinde gerçekleştiği, 1-4 haftalık sabit zaman kutusu.
2.  **Sprint Planning (Sprint Planlama):** Sprint başında, Product Owner ve Geliştirme Ekibi'nin bir araya gelerek o Sprint'te hangi işlerin yapılacağını planladığı toplantı.
3.  **Daily Scrum (Günlük Scrum):** Her gün aynı saatte yapılan, 15 dakikalık kısa bir toplantı. Ekip üyeleri üç soruyu yanıtlar: "Dün ne yaptım?", "Bugün ne yapacağım?", "Beni engelleyen bir şey var mı?".
4.  **Sprint Review (Sprint Değerlendirmesi):** Sprint sonunda, yapılan işlerin (Increment) paydaşlara sunulduğu ve geri bildirim alındığı toplantı.
5.  **Sprint Retrospective (Sprint Retrospektifi):** Sprint Review'dan sonra, Scrum ekibinin kendi içinde yaptığı, süreci nasıl daha iyi hale getirebileceklerini konuştukları bir toplantı ("Neyi iyi yaptık? Neyi daha iyi yapabiliriz?").

**Scrum'ın 3 Artefaktı (Artifacts):**
1.  **Product Backlog:** Projede yapılması istenen tüm işlerin (kullanıcı hikayeleri, özellikler) önceliklendirilmiş listesi. Dinamiktir, sürekli değişebilir.
2.  **Sprint Backlog:** Sprint Planlama'da seçilen ve o Sprint'te tamamlanması hedeflenen işlerin listesi.
3.  **Increment (Artım):** Her Sprint sonunda ortaya çıkan, potansiyel olarak yayınlanabilir, çalışan ürün parçası.

**Ne Zaman Kullanılır?**
*   Gereksinimlerin belirsiz olduğu veya sık sık değiştiği projelerde.
*   Hızlı bir şekilde pazara bir ürün çıkarmak ve geri bildirimle ürünü geliştirmek istendiğinde.
*   Yazılım geliştirme, ürün geliştirme, pazarlama kampanyaları gibi karmaşık ve yaratıcı işlerde.

##### **Kanban Çerçevesi**

Kanban, Japonca'da "görsel kart" veya "sinyal" anlamına gelir. Ana felsefesi, iş akışını **görselleştirmek** ve **devam eden iş miktarını (Work in Progress - WIP) sınırlamaktır.**

**Kanban'ın Temel Prensipleri:**
1.  **İş Akışını Görselleştir (Visualize the Workflow):** Genellikle bir **Kanban Tahtası** kullanılır. Bu tahta, işin aşamalarını gösteren sütunlardan oluşur (Örn: "Yapılacaklar / To Do", "Yapılıyor / In Progress", "Test Ediliyor / In Test", "Bitti / Done"). İşler, bu sütunlar arasında hareket eden kartlarla temsil edilir.
2.  **Devam Eden İşi Sınırla (Limit WIP):** Her sütun için aynı anda en fazla kaç işin bulunabileceğine dair bir sınır (WIP Limiti) konur. Örneğin, "Yapılıyor" sütununun WIP limiti 2 ise, bir geliştirici aynı anda en fazla 2 görev üzerinde çalışabilir. Bu, ekibin odaklanmasını sağlar, darboğazları (bottlenecks) ortaya çıkarır ve işlerin daha hızlı tamamlanmasına yardımcı olur.
3.  **Akışı Yönet (Manage Flow):** Amaç, kartların tahtada soldan sağa doğru mümkün olan en hızlı ve en akıcı şekilde hareket etmesini sağlamaktır.
4.  **Süreç Politikalarını Açıkça Belirle:** "Bir iş ne zaman 'Bitti' sayılır?" gibi kuralları herkesin anlayacağı şekilde tanımlamak.
5.  **Geri Bildirim Döngüleri Uygula:** Sürekli iyileştirme için düzenli toplantılar yapmak.



**Ne Zaman Kullanılır?**
*   Sürekli bir iş akışının olduğu durumlarda (örn: destek talepleri, bakım işleri, sürekli teslimat).
*   Scrum gibi katı zaman kutularının uygun olmadığı, işlerin sürekli geldiği ortamlarda.
*   Mevcut bir süreci yavaş yavaş iyileştirmek istendiğinde.

#### Hibrit Yaklaşımlar
Gerçek hayatta, birçok organizasyon saf Şelale veya saf Agile kullanmaz. Genellikle ikisinin bir karışımı olan **Hibrit** modelleri tercih ederler. Örneğin, projenin genel planlaması ve bütçelemesi Şelale gibi en başta yapılırken (yüksek seviye planlama), ürünün geliştirilmesi Agile/Scrum kullanılarak Sprint'ler halinde yapılabilir. Bu, kurumsal yönetim beklentileri ile geliştirme ekibinin esnekliğini birleştirmenin bir yoludur.

---

## Bölüm 2: Risk Yönetimi (Tahmini Süre: 2.5 Saat)

Projeler belirsizliklerle doludur. Risk yönetimi, bu belirsizlikleri projenin lehine çevirme veya projeye zarar vermelerini engelleme sanatıdır.

### 2.1. Risk Nedir?

> **Tanım: Risk**, gerçekleşmesi halinde proje hedefleri (kapsam, zaman, maliyet, kalite) üzerinde **pozitif** veya **negatif** bir etkiye sahip olabilecek, **belirsiz** bir olay veya durumdur.

Bu tanımda üç önemli nokta var:
1.  **Belirsizlik:** Risk, henüz gerçekleşmemiş bir şeydir. "Sunucu çöktü" bir risk değil, bir **sorundur (issue)**. "Sunucunun çökme ihtimali var" ise bir **risktir**.
2.  **Etki:** Eğer risk gerçekleşirse, projenin gidişatını etkiler.
3.  **Pozitif veya Negatif:** Genellikle riski sadece olumsuz bir şey olarak düşünürüz (tehdit). Ancak risklerin olumlu tarafları da olabilir (fırsat).
    *   **Tehdit (Threat):** Projeye zarar verme potansiyeli olan risk. *Örnek: "Kullanacağımız yeni kütüphanede kritik bir hata çıkması."*
    *   **Fırsat (Opportunity):** Projeye fayda sağlama potansiyeli olan risk. *Örnek: "Dolar kurunun düşmesiyle donanım maliyetlerimizin beklenenden az olması."*

### 2.2. Risk Yönetimi Süreci

Risk yönetimi, "Umarım kötü bir şey olmaz" demek yerine, "Kötü bir şey olursa ne yapacağımızı biliyoruz" demektir. Bu, 6 adımlık sistematik bir süreçtir.

#### Adım 1: Risk Yönetimini Planlama
Bu ilk adımda, projenin geri kalanında risk yönetimini **nasıl** yapacağımızı planlarız.
*   Hangi araçları kullanacağız?
*   Kimler sorumlu olacak?
*   Riskleri nasıl kategorize edeceğiz (teknik, dışsal, organizasyonel vb.)?
*   Olasılık ve etki seviyelerini nasıl tanımlayacağız (örn: Düşük, Orta, Yüksek)?

#### Adım 2: Riskleri Tanımlama (Identification)
Bu, projenin potansiyel risklerini (hem tehditler hem de fırsatlar) listelediğimiz yaratıcı bir süreçtir.
*   **Amaç:** Olabildiğince çok riski erkenden tespit etmek.
*   **Kullanılan Teknikler:**
    *   **Beyin Fırtınası:** Proje ekibi ve paydaşlarla bir araya gelip "Bu projede ne ters gidebilir? Ne beklediğimizden daha iyi gidebilir?" sorularını sormak.
    *   **Uzman Görüşü (Delphi Tekniği):** Konuyla ilgili uzmanlara danışmak.
    *   **Kontrol Listeleri:** Geçmiş projelerden öğrenilen derslere dayalı hazır risk listelerini kullanmak.
    *   **SWOT Analizi:** Projenin Güçlü (Strengths), Zayıf (Weaknesses) yönlerini ve dış çevrenin Fırsatlarını (Opportunities), Tehditlerini (Threats) analiz etmek.

**Örnek Senaryo: "HızlıAl E-Ticaret Uygulaması" Projesi İçin Risk Tanımlama**
*   **Teknik Riskler:**
    *   Ödeme altyapısı entegrasyonunun beklenenden uzun sürmesi (Tehdit).
    *   Seçilen bulut sağlayıcısının beklenmedik bir performans artışı sunması (Fırsat).
    *   Kullanılan açık kaynaklı bir kütüphanenin güvenlik açığı barındırması (Tehdit).
*   **Dışsal Riskler:**
    *   Rakip bir firmanın benzer bir uygulamayı daha önce piyasaya sürmesi (Tehdit).
    *   Yeni bir veri koruma yasasının çıkması ve ek geliştirme gerektirmesi (Tehdit).
*   **Organizasyonel Riskler:**
    *   Projedeki kilit bir geliştiricinin işten ayrılması (Tehdit).
    *   Pazarlama departmanının uygulamayı tanıtmak için yeterli bütçe alamaması (Tehdit).

#### Adım 3: Niteliksel Risk Analizi (Qualitative Analysis)
Tanımlanan uzun risk listesini önceliklendirme adımıdır. Her riskin **gerçekleşme olasılığı** ve gerçekleşirse **proje üzerindeki etkisi** değerlendirilir.
*   **Amaç:** Hangi risklere odaklanmamız gerektiğini belirlemek.
*   **Araç: Olasılık ve Etki Matrisi**
    *   Her risk için "Olasılık" (1'den 5'e veya Düşük/Orta/Yüksek) ve "Etki" (1'den 5'e veya Düşük/Orta/Yüksek) skorları verilir.
    *   Bu iki skor çarpılarak bir **Risk Skoru** elde edilir.
    *   Skoru yüksek olan riskler, en çok dikkat edilmesi gerekenlerdir.

**Örnek Olasılık ve Etki Matrisi:**

| | **Etki (Impact)** | | | | |
| :--- | :--- | :--- | :--- | :--- | :--- |
| **Olasılık (Probability)** | **1 (Çok Düşük)** | **2 (Düşük)** | **3 (Orta)** | **4 (Yüksek)** | **5 (Çok Yüksek)** |
| **5 (Çok Yüksek)** | 5 | 10 | 15 (Yüksek) | 20 (Yüksek) | 25 (Yüksek) |
| **4 (Yüksek)** | 4 | 8 | 12 (Orta) | 16 (Yüksek) | 20 (Yüksek) |
| **3 (Orta)** | 3 | 6 (Düşük) | 9 (Orta) | 12 (Orta) | 15 (Yüksek) |
| **2 (Düşük)** | 2 | 4 (Düşük) | 6 (Düşük) | 8 (Orta) | 10 (Orta) |
| **1 (Çok Düşük)** | 1 (Düşük) | 2 (Düşük) | 3 (Düşük) | 4 (Düşük) | 5 (Düşük) |

Matristeki Kırmızı/Sarı/Yeşil alanlar gibi düşünün. Yüksek skorlu (kırmızı alan) riskler acil eylem gerektirir.

#### Adım 4: Niceliksel Risk Analizi (Quantitative Analysis)
Bu, isteğe bağlı ve daha ileri bir adımdır. Niteliksel analizde önceliklendirilen risklerin proje hedefleri (özellikle zaman ve maliyet) üzerindeki etkisini **sayısal olarak** analiz eder. Monte Carlo Simülasyonu gibi istatistiksel teknikler kullanılır. Bu dersin kapsamında bu konunun sadece varlığını bilmeniz yeterlidir.

#### Adım 5: Risk Yanıtlarını Planlama (Response Planning)
Öncelikli riskler için ne yapacağımıza karar verdiğimiz adımdır. Her risk için bir strateji belirlenir.

**Tehditler (Negatif Riskler) için Stratejiler:**

1.  **Kaçınma (Avoid):** Riskin ortaya çıkma olasılığını sıfıra indirmek için proje planını değiştirmek. En etkili yöntemdir.
    *   *Örnek:* "Kullanacağımız yeni ve test edilmemiş kütüphanede hata çıkma riski var." -> **Kaçınma:** Bu kütüphaneyi kullanmaktan vazgeçip, daha önce kullandığımız, stabil ve bildiğimiz bir kütüphaneyi tercih etmek.

2.  **Aktarma (Transfer):** Riskin etkisini ve sorumluluğunu üçüncü bir tarafa devretmek. Risk ortadan kalkmaz, sadece sahibi değişir. Genellikle sigorta veya dış kaynak kullanımı (outsourcing) ile yapılır.
    *   *Örnek:* "Sunucularımızın siber saldırıya uğrama riski var." -> **Aktarma:** Sunucu barındırma ve güvenliği işini, bu konuda uzmanlaşmış bir bulut sağlayıcısına (AWS, Azure, Google Cloud) devretmek.

3.  **Azaltma (Mitigate):** Riskin gerçekleşme **olasılığını** veya gerçekleşirse **etkisini** düşürmeye yönelik aksiyonlar almak. En yaygın kullanılan stratejidir.
    *   *Örnek:* "Projedeki kilit bir geliştiricinin işten ayrılma riski var." -> **Azaltma:** Proje dokümantasyonunu çok iyi tutmak, kod içinde "pair programming" (ikili programlama) yapmak ve bilgi paylaşımını teşvik ederek tek bir kişiye olan bağımlılığı azaltmak.

4.  **Kabul Etme (Accept):** Risk için hiçbir aksiyon almamak.
    *   **Pasif Kabul:** "Olursa olur" demek. Genellikle düşük olasılıklı ve düşük etkili riskler için kullanılır.
    *   **Aktif Kabul:** Risk gerçekleşirse ne yapılacağına dair bir acil durum planı (contingency plan) hazırlamak. Örneğin, zaman veya bütçe yedeği ayırmak.
    *   *Örnek:* "Ofisteki yazıcının bozulma riski." (Etkisi düşük) -> **Pasif Kabul:** Bozulursa tamir ettiririz.

**Fırsatlar (Pozitif Riskler) için Stratejiler:**

1.  **Faydalanma (Exploit):** Fırsatın gerçekleşme olasılığını %100'e çıkarmak için proaktif davranmak.
    *   *Örnek:* "Eğer yeni bir özelliği rakipten önce çıkarırsak, pazar payı kapma fırsatı var." -> **Faydalanma:** Bu özelliğe en yetenekli geliştiricileri atamak ve projenin o kısmına öncelik vererek kesinlikle zamanında bitmesini sağlamak.

2.  **Geliştirme (Enhance):** Fırsatın gerçekleşme **olasılığını** veya gerçekleşirse **pozitif etkisini** artırmaya yönelik aksiyonlar almak.
    *   *Örnek:* "Kullanacağımız yeni bir teknoloji, uygulamanın performansını beklenenden fazla artırma fırsatı sunuyor." -> **Geliştirme:** Bu teknolojiyi denemek için bir prototip yapmak ve potansiyelini tam olarak nasıl kullanabileceğimizi araştırmak.

3.  **Paylaşma (Share):** Fırsatı, ondan daha iyi yararlanabilecek üçüncü bir tarafla (örneğin bir iş ortağı) paylaşmak.
    *   *Örnek:* "Geliştirdiğimiz bir algoritma, başka bir sektörde de kullanılma potansiyeli taşıyor." -> **Paylaşma:** Bu algoritmayı o sektördeki bir firma ile ortak bir girişim (joint venture) kurarak ticarileştirmek.

4.  **Kabul Etme (Accept):** Fırsattan yararlanmak için özel bir çaba göstermemek, ancak gerçekleşirse faydalarını memnuniyetle karşılamak.

#### Adım 6: Riskleri İzleme ve Kontrol Etme
Bu, proje boyunca devam eden bir süreçtir.
*   **Amaç:** Planlanan risk yanıtlarının işe yarayıp yaramadığını takip etmek, mevcut risklerdeki değişiklikleri izlemek ve yeni ortaya çıkan riskleri tespit etmek.
*   **Araç: Risk Kayıt Tablosu (Risk Register)**
    *   Bu, projenin tüm tanımlanmış risklerini, analiz sonuçlarını, yanıt planlarını ve mevcut durumlarını içeren canlı bir belgedir.

**Örnek Risk Kayıt Tablosu Şablonu:**

| ID | Risk Açıklaması | Kategori | Olasılık (1-5) | Etki (1-5) | Risk Skoru | Risk Yanıt Stratejisi | Yanıt Planı | Sorumlu | Durum |
|:---|:---|:---|:---:|:---:|:---:|:---|:---|:---|:---|
| R01 | Kilit geliştiricinin (Ahmet) projeden ayrılması | İnsan Kaynakları | 3 | 5 | 15 | Azaltma (Mitigate) | Proje dokümantasyonu detaylandırılacak. Ayşe, Ahmet ile pair programming yapacak. | Proje Yöneticisi | Açık |
| R02 | Ödeme altyapısı API'sinin stabil olmaması | Teknik | 4 | 4 | 16 | Azaltma (Mitigate) | API için kapsamlı bir test senaryosu seti oluşturulacak. Alternatif bir ödeme sağlayıcısı araştırılacak. | Teknik Lider | İzleniyor |
| R03 | Dolar kurunun düşmesiyle donanım maliyetlerinin azalması (Fırsat) | Finansal | 2 | 3 | 6 | Kabul Etme (Accept) | Bütçede oluşacak fazlalık, acil durum yedeğine eklenecek. | Proje Yöneticisi | Açık |

---

## Bölüm 3: Değişiklik Yönetimi (Tahmini Süre: 1.5 Saat)

Değişim, projelerin doğasında vardır. Müşteri fikrini değiştirir, teknoloji gelişir, pazar koşulları farklılaşır. Değişiklik Yönetimi, bu değişimlerin projeyi kaosa sürüklemesini engelleyen kontrollü bir süreçtir.

### 3.1. Projelerde Değişiklik Neden Olur ve Neden Yönetilmelidir?

Eğer bir projede değişiklikler kontrolsüz bir şekilde kabul edilirse, **Kapsam Kayması (Scope Creep)** denen tehlikeli durum ortaya çıkar. Kapsam kayması, projenin başlangıçta tanımlanan hedeflerinin ve sınırlarının, küçük ve sürekli eklemelerle, fark ettirmeden büyümesidir.

**Kapsam Kaymasının Sonuçları:**
*   Proje takvimi uzar.
*   Proje bütçesi aşılır.
*   Ekip yorulur ve motivasyonunu kaybeder.
*   Projenin kalitesi düşer.
*   Proje başarısız olabilir.

Değişiklik Yönetimi, her değişiklik talebinin fayda ve maliyetinin dikkatlice analiz edilmesini ve sadece projeye gerçekten değer katanların, kontrollü bir şekilde plana dahil edilmesini sağlar. Amaç, değişimi engellemek değil, **yönetmektir**.

### 3.2. Değişiklik Yönetimi Süreci

İyi bir değişiklik yönetimi süreci genellikle şu adımları takip eder:

**Adım 1: Değişiklik Talebinin Tanımlanması ve Resmi Olarak İletilmesi**
*   Herhangi bir paydaş (müşteri, kullanıcı, ekip üyesi) bir değişiklik talep ettiğinde, bunu sözlü olarak değil, **Değişiklik Talep Formu (Change Request Form - CRF)** gibi standart bir formatta yazılı olarak iletmelidir.
*   Bu form, değişikliğin ne olduğunu, neden gerekli olduğunu ve beklenen faydalarını açıkça belirtmelidir.

**Adım 2: Değişiklik Talebinin Etki Analizi**
*   Talep alındıktan sonra, Proje Yöneticisi veya ilgili ekip üyeleri bu değişikliğin proje üzerindeki potansiyel etkilerini analiz eder.
*   **Analiz Edilen Başlıklar:**
    *   **Kapsama Etkisi:** Bu değişiklik hangi yeni işleri gerektiriyor, hangi mevcut işleri etkiliyor?
    *   **Zamana Etkisi:** Proje takvimini ne kadar uzatacak?
    *   **Maliyete Etkisi:** Ne kadar ek bütçe gerektirecek?
    *   **Kaliteye Etkisi:** Ürünün kalitesini artıracak mı, azaltacak mı?
    *   **Riske Etkisi:** Yeni riskler doğuruyor mu?

**Adım 3: Değişiklik Talebinin Değerlendirilmesi ve Karar (Onay/Red)**
*   Etki analizi tamamlandıktan sonra, talep karar merciine sunulur. Küçük projelerde bu kişi Proje Yöneticisi olabilir. Büyük ve karmaşık projelerde ise genellikle **Değişiklik Kontrol Kurulu (Change Control Board - CCB)** adı verilen bir komite bu kararı verir.
*   CCB, genellikle proje sponsoru, kilit paydaşlar, proje yöneticisi ve teknik liderlerden oluşur.
*   Kurul, etki analizini inceler ve değişikliğin getireceği faydanın, getireceği maliyete (zaman, para, efor) değip değmeyeceğine karar verir. Talep **onaylanabilir**, **reddedilebilir** veya **ertelenebilir**.

**Adım 4: Kararın İletilmesi ve Onaylanan Değişikliğin Uygulanması**
*   Verilen karar, talebi yapan kişiye ve tüm ilgili paydaşlara bildirilir.
*   Eğer değişiklik onaylandıysa:
    *   Proje Yönetim Planı (kapsam, zaman, maliyet belgeleri) güncellenir.
    *   Bu güncelleme tüm ekibe duyurulur.
    *   Değişiklik, proje iş akışına dahil edilir ve uygulanır.

**Adım 5: Değişikliğin Doğrulanması ve Kapanış**
*   Uygulama tamamlandıktan sonra, değişikliğin doğru bir şekilde yapıldığı ve istenen sonucu verdiği test edilir ve doğrulanır.
*   Değişiklik talep kaydı "Tamamlandı" olarak kapatılır.

### 3.3. Pratik Uygulama: Değişiklik Talep Formu

Aşağıda, "HızlıAl E-Ticaret Uygulaması" projesi için doldurulmuş örnek bir Değişiklik Talep Formu bulunmaktadır.

**DEĞİŞİKLİK TALEP FORMU (CRF)**

| **Talep ID:** CR-014 | **Proje Adı:** HızlıAl E-Ticaret Uygulaması | **Tarih:** 25.10.2023 |
| :--- | :--- | :--- |
| **Talebi Yapan:** Pazarlama Departmanı | **Talebi Alan:** Proje Yöneticisi |
| --- | --- | --- |
| **Değişiklik Açıklaması:**<br>Kullanıcıların ürün detay sayfasında, ürünü sosyal medyada (Facebook, Twitter) paylaşabilmeleri için bir "Paylaş" butonu eklenmesi. |
| **Değişikliğin Gerekçesi:**<br>Uygulamanın viral pazarlama potansiyelini artırmak ve marka bilinirliğini organik olarak yaymak. |
| **Beklenen Fayda:**<br>Kullanıcı etkileşiminin artması, yeni kullanıcıların uygulamayı keşfetmesi. |
| --- | --- | --- |
| **ETKİ ANALİZİ (Proje Ekibi Tarafından Doldurulur)** |
| **Kapsama Etkisi:**<br>- Arayüz (UI/UX) tasarımı yapılacak.<br>- Frontend geliştirme (buton ve paylaşım fonksiyonu) yapılacak.<br>- Backend tarafında bir değişiklik gerekmiyor.<br>- Test senaryoları güncellenecek. |
| **Zamana Etkisi:**<br>Tahmini ek süre: 5 iş günü. | **Maliyete Etkisi:**<br>Tahmini ek maliyet: 8.000 TL (geliştirici ve test uzmanı eforu). |
| **Diğer Etkiler (Risk, Kalite vb.):**<br>Yeni bir risk öngörülmüyor. Kalite üzerinde olumlu etki bekleniyor. |
| --- | --- | --- |
| **DEĞİŞİKLİK KONTROL KURULU (CCB) KARARI** |
| **Karar:** [X] Onaylandı [] Reddedildi [] Ertelendi | **Karar Tarihi:** 27.10.2023 |
| **Açıklama/Şartlar:**<br>Pazarlama potansiyeli, ek maliyet ve süreye göre daha değerli bulunmuştur. Mevcut Sprint sonrasında planlanacaktır. |
| **Onaylayan:** CCB Başkanı |

### 3.4. Bilgisayar Mühendisliğinde Değişiklik Yönetimi

Bilgisayar mühendisleri için değişiklik yönetimi, kod ve konfigürasyon yönetimi ile doğrudan ilişkilidir.
*   **Sürüm Kontrol Sistemleri (Version Control Systems - VCS):** **Git** gibi araçlar, değişiklik yönetiminin teknik uygulamasının merkezindedir. Her onaylanmış değişiklik, yeni bir `commit` veya bir `feature branch` (özellik dalı) olarak kod tabanına entegre edilir.
*   **Commit Mesajları:** İyi yazılmış `commit` mesajları, "hangi değişikliğin, neden yapıldığını" anlatan mini değişiklik kayıtlarıdır. `CR-014: Add social media sharing feature` gibi bir `commit` mesajı, değişikliği doğrudan resmi talep formuna bağlar.
*   **Pull/Merge Request'ler:** Bu mekanizmalar, kod değişikliklerinin ana dala (örn: `main` veya `develop`) entegre edilmeden önce bir gözden geçirme (code review) sürecinden geçmesini sağlar. Bu, CCB'nin karar sürecinin teknik bir yansımasıdır.

Kısacası, proje seviyesindeki resmi değişiklik yönetimi süreci, kod seviyesindeki disiplinli sürüm kontrol pratikleri ile desteklendiğinde en etkili hale gelir.

---

## Bölüm 4: Kapanış ve Değerlendirme (Tahmini Süre: 30 Dakika)

Tebrikler! Modern mühendislik pratiğinin üç temel direği olan Proje, Risk ve Değişiklik Yönetimi konularındaki bu yoğun çalışmayı tamamladınız. Şimdi öğrendiklerimizi özetleyelim ve büyük resmi görelim.

### 4.1. Genel Özet ve Büyük Resim

Bu üç disiplin ayrı ayrı değil, birbiriyle sürekli etkileşim halinde, entegre bir bütün olarak çalışır.

*   **Proje Yönetimi**, projenin yol haritasını çizer (NE, NE ZAMAN, NE KADARA yapılacak?). Bu, ana çerçevedir.
*   **Risk Yönetimi**, bu yolda karşımıza çıkabilecek potansiyel engelleri (tehditler) ve kestirmeleri (fırsatlar) öngörür ve bunlara karşı hazırlıklı olmamızı sağlar. Proje planını daha gerçekçi ve dayanıklı hale getirir.
*   **Değişiklik Yönetimi**, yolculuk sırasında rotayı değiştirmek istediğimizde bunu güvenli bir şekilde yapmamızı sağlar. Her değişiklik talebi, aslında proje planı için potansiyel bir **risktir** (zaman ve bütçeyi aşma riski). Değişiklik yönetimi süreci, bu riski analiz edip yönetir. Onaylanan her değişiklik, **proje planının** (kapsam, zaman, maliyet) güncellenmesini gerektirir.

**Senaryo:** "HızlıAl" projesinde, müşteri "kullanıcı profiline anket ekleme" **değişikliği** talep etti.
1.  **Değişiklik Yönetimi** süreci başlar. Talep formu doldurulur.
2.  Etki analizi yapılır: Bu değişikliğin maliyeti 10.000 TL ve süresi 1 hafta uzayacak.
3.  Aynı zamanda bu bir **Risk Analizidir**: "Bütçeyi ve takvimi aşma **riski**" ortaya çıktı.
4.  CCB, bu değişikliği onaylarsa, **Proje Yönetimi** devreye girer: Proje planı güncellenir. Yeni bütçe ve yeni teslim tarihi belirlenir.

Gördüğünüz gibi, bu üç alan, başarılı bir projeyi yönetmek için ayrılmaz bir takımdır. Bu standartları ve süreçleri anlamak ve uygulamak, sizi sadece kod yazan bir mühendisten, bir değer yaratan, problem çözen ve liderlik potansiyeli taşıyan bir profesyonele dönüştürecektir.

### 4.2. Sınav Öncesi Kendini Değerlendirme Soruları

Aşağıdaki soruları, materyale geri dönmeden cevaplamaya çalışarak bilginizi test edin. Cevaplarınızdan emin değilseniz, ilgili bölümü tekrar gözden geçirin.

**Proje Yönetimi Soruları:**
1.  Bir projeyi operasyonel bir işten ayıran iki temel özellik nedir? Açıklayınız.
2.  Proje kısıtları üçgeninin (Altın Üçgen) elemanları nelerdir ve aralarında nasıl bir ilişki vardır? Bir örnekle açıklayınız.
3.  Proje yaşam döngüsünün 5 fazını sırasıyla yazınız ve her fazın temel amacını bir cümleyle özetleyiniz.
4.  Şelale (Waterfall) ve Çevik (Agile) metodolojileri arasındaki en temel fark nedir? Hangi durumda Şelale, hangi durumda Agile (örneğin Scrum) daha uygun olur?
5.  Scrum'daki Product Owner, Scrum Master ve Geliştirme Ekibi'nin sorumlulukları nelerdir?
6.  Bir Kanban tahtasının temel amacı nedir ve "WIP Limiti" ne işe yarar?

**Risk Yönetimi Soruları:**
7.  Risk ile Sorun (Issue) arasındaki fark nedir? Birer örnek veriniz.
8.  Bir riskin hem pozitif (fırsat) hem de negatif (tehdit) olabileceğini birer örnekle açıklayınız.
9.  Risk yönetimi sürecinin 6 adımını sırasıyla sayınız.
10. Niteliksel Risk Analizi'nde kullanılan Olasılık ve Etki Matrisi'nin amacı nedir?
11. Bir tehdide (negatif risk) karşı kullanılabilecek 4 temel yanıt stratejisi nedir? Her birini kısaca açıklayınız.
12. Risk Kayıt Tablosu (Risk Register) nedir ve ne için kullanılır?

**Değişiklik Yönetimi Soruları:**
13. "Kapsam Kayması" (Scope Creep) ne demektir ve projeler için neden tehlikelidir?
14. Kontrollü bir değişiklik yönetimi sürecinin temel adımları nelerdir?
15. Değişiklik Kontrol Kurulu'nun (CCB) rolü ve sorumluluğu nedir?
16. Bir bilgisayar mühendisi için Git gibi sürüm kontrol sistemleri ile değişiklik yönetimi süreci arasında nasıl bir ilişki vardır?

### 4.3. Sonraki Adımlar

Bu materyali başarıyla tamamladınız. Artık mühendislik uygulamalarında kullanılan temel yönetim standartları hakkında sağlam bir bilgiye sahipsiniz.

Bir sonraki adımınız, bu konulardaki bilginizi ölçecek olan sınava girmektir. Sınav, bu materyalde işlenen tüm konuları, tanımları, süreçleri ve örnekleri kapsayacaktır. Kendini değerlendirme sorularına rahatlıkla cevap verebiliyorsanız, sınava hazırsınız demektir.
