Skip to main content
Geri
Diğer dilde de mevcut: 🇬🇧 English

Mühendisler İçin Agile: Manifesto'dan Pratik Scrum'a Tek Okumada

📋

Özet

  • Moda Terimin Ötesinde: Agile sadece 2001’deki bir kayak gezisiyle ilgili değildir; Pazartesi sendromuna dönüşen iş listesi kaygısı ve değişen beklentilerin çözümüdür.
  • Tahmin Gerçekliği: Geleneksel modeller kontrol illüzyonu sunar. Agile, yüksek belirsizlik altında hata yapmanın maliyetini düşürme disiplini sağlar.
  • Hayatta Kalma Rehberi: Manifesto bir dua değildir; zor zamanlar için bir karar verme çerçevesidir. Scrum bu değerleri güçlendirir.
  • Görünürlük Tuzağı: Agile’ı benimsemek genellikle kaosu geçici olarak artırır çünkü sorunları saklamayı bırakır ve takımı onlarla yüzleşmeye zorlar.

İnternetteki çoğu makale Agile hikayesine, 2001 yılında Utah’daki bir kayak merkezinde toplanan 17 kişiyle başlar. Ama dürüst olalım: Sizin asıl derdiniz bu değil.

Sizin derdiniz; Pazartesi sabahı o bitmeyen backlog, müşterinin sürekli değişen beklentileri, yetişmeyen işler ve o meşhur soru: “Bunu neden hala teslim edemiyoruz?”

Bu seri, Agile’ın sadece “havalı bir kelime” olmadığını, doğru (ve yanlış) uygulandığında bir takımın hayatını nasıl doğrudan etkilediğini uçtan uca anlatmak için tasarlandı. Teori ile değil, sahadaki gerçek sancılarla.

Agile Serisi — Kopya Kağıdı’nın 1. Bölümü.

1. Neden Agile? (Tahmin İllüzyonu vs. Gerçeklik)

Geleneksel (Waterfall) yöntemler, geleceği en baştan mükemmel bir şekilde tahmin edebileceğimiz varsayımına dayanır. Bu kulağa güven verici gelir ama tehlikeli bir yanılsamadır.

Agile’ı şu sebeple yaparız: Yanılmaktan korktuğumuz için değil, geç yanılmaktan korktuğumuz için. 6 ay sonra yanlış şeyi teslim etmek bir felakettir; 2 hafta sonra “yanlış yoldayız” demek başarısızlık değil, öğrenmedir.

2. Manifesto: Bir Dua Değil, Bir Hayatta Kalma Rehberi

Agile Manifestosu’ndaki değerler duvara asmak için değil, zor anlarda karar vermek içindir. Scrum, bu değerleri yaşatmak için kullanılan en yaygın çerçevedir. Ancak net olalım: Scrum bir toplantılar bütünü değildir.

01

Bireyler ve Etkileşimler

Jira statülerinden daha önemlisi, birinin Daily Standup’ta şöyle demesidir: “Takıldım, yardıma ihtiyacım var.”

02

Çalışan Yazılım

Kimse 100 sayfalık analiz dokümanı okumaz. Ama çalışan, tıklanabilir bir özellik gerçek geri bildirim yaratır. Sprint Review’un odağı budur.

03

Müşteri İşbirliği

Jeff Patton’ın User Story Mapping (2014) kitabında vurguladığı gibi, amaç “ne yapacağımızı bir yere yazmak” değil, ortak anlayış (shared understanding) yaratmaktır.

04

Değişime Yanıt Vermek

Sprint Planning (Planlama), rotayı düzenli olarak düzeltme cesaretini verir.

3. Ama Bunu Kimse Söylemiyor: Başta İşler Karışabilir!

Agile’a geçtiğinizde her şey bir anda düzelmez. Hatta bir süre daha kaotik olabilir. Çünkü Agile sorunları çözmez; onları görünür kılar. Tıpkı bizim yaşadığımız gibi:

  • Retrospektifler süreç iyileştirme alanı olmalıdır ama kişisel algılanabilir.
  • Müşteriye “Sprint başladı, çok acil değilse bunu değiştirmeyelim” demek zordur.
  • İşi yaparken soru sorduğumuz için sürekli bir git-gel ve bağlam değişimi (context switching) olur.

Agile kaosu bitirmez; sorunların halı altına süpürülmesini engeller.

4. Pratik Bir Senaryo: “Bir Bug Çıktı. Şimdi Ne Olacak?”

Bir gün canlı ortamda (production) ciddi bir hata (bug) çıktı ve cevabın Scrum Kılavuzu’nda net bir şekilde yazmadığını fark ettik. Manifesto’ya bakarak kendi karar ağacımızı oluşturduk:

1

Etki Analizi

Bu hata kaç kullanıcıyı etkiliyor? İş etkisi ne? Eğer küçükse: bir sonraki sprint’i beklesin (Bilinçli Erteleme).

2

Sprint Hedefi Kontrolü

Hata önemli ama sprint’i bozmadan küçük bir ekstra eforla çözebilir miyiz? Evet ise: Yap.

3

Takas (Trade-off)

Eğer hata büyükse ve sprint’i bozacaksa: Sorun, “Bunu yapmak için Sprint’ten neyi çıkarabiliriz?”, şeffaf olun ve bir Takas yapın.

4

Nükleer Seçenek

Eğer hata çok büyük, acil ve tüm takımı gerektiriyorsa, dürüst olun: Sprint’i Durdurun, sorunu çözün ve yeniden planlayın.

Bu akış Scrum kitabında yazmaz ama Agile Manifestosu’nun ruhunda vardır (Değişime yanıt vermek).

5. Neden Scrum? (Çerçeve Spektrumu)

Takeuchi ve Nonaka’nın ünlü 1986 makalesi, takımların bir “rugby takımı” gibi bütünsel hareket etmesi gerektiğini savunur. Scrum, bu felsefenin en yaygın disiplinidir.

ÇerçeveOdak NoktasıNe Zaman Seçilmeli?
ScrumKarmaşıklık ve TeslimatBelirsizliğin yüksek olduğu ürünler için.
KanbanSürekli AkışOperasyon ve destek takımları için.
XPMühendislik KalitesiEğer teknik mükemmellik (TDD, Pair Programming) öncelikse.

6. Agile Kanun Değil, Anayasadır

Scrum Kılavuzu rolleri ve ritüelleri açıklar ama her sorunun cevabını vermez. Çünkü Agile:

  • Bir reçete veya kanun kitabı değildir.
  • Kesinlikle ezbere uygulanacak bir kontrol listesi değildir.

Agile bir anayasa gibidir; ilkeleri verir, yorumlamayı ve yaşatmayı takıma bırakır. Eğer her sorunu “Scrum’da bu yazıyor mu?” diye sorarak çözmeye çalışırsanız, Scrum yaparsınız ama Agile olamazsınız.

Agile Serisini Keşfedin

Bu genel bakış sahneyi kurdu. Sürecin her adımında ustalaşmak için serinin detaylarına dalın:

🏁

Sonuç

Agile kaosu bitirmez ama yönetilebilir kılar. Hata yapmanızı engellemez ama onları geç fark etmenizi engeller. Başta zor olacak; Retrolar gergin geçecek, Sprintler patlayacak. Ama tam da bu yüzden değerlidir.

Agile bir varış noktası değil, zor kararlar verme kasıdır. Ve o kas sadece kullandıkça gelişir.

📚

Kaynaklar

Share this article

Suggested hashtags (click to copy):

LinkedIn Twitter