Yazılım Proje Yönetimi ve Agile/Scrum: Modern Teknoloji Ekipleri Nasıl Çalışır?

Yazılım proje yönetimi nedir ve Agile ile Scrum bu işin neresinde durur?

Yazılım proje yönetimi, bir yazılım ürününü planlama, önceliklendirme, geliştirme ve teslim etme sürecini düzenleyen disiplindir. Agile bu işe kısa döngüler ve sürekli geri bildirim felsefesini getirir. Scrum ise bu felsefeyi rolleri, etkinlikleri ve çıktıları belli, hafif bir çerçeveye dönüştürür. Kanban da akışı görünür kılan ikinci yaygın yöntemdir.

Yazılım proje yönetimi konusunu bana en çok web tasarım ve e-ticaret projelerinde birlikte çalıştığım müşteriler soruyor. Çünkü ajansın ya da yazılım ekibinin "sprint", "backlog" gibi kelimeleri neden kullandığını merak ediyorlar. 2012'den beri sahadayım; bu yazıda teoriyi resmi kaynaklara, gözlemleri ise kendi tecrübeme dayandırıyorum. Araç karşılaştırmasına girmiyorum, onu ayrı bir yazıda ele alıyorum.

Klasik şelale yöntemi yazılım projelerinde neden sık tıkanır?

Şelale modelinde işi sırayla yürütürsünüz: önce gereksinim, sonra tasarım, ardından kodlama, test ve teslim. Kâğıt üzerinde düzenli görünür. Ancak yazılımda gereksinimler projenin ortasında değişir. Müşteri ilk ekranı gördüğünde fikrini netleştirir, pazar değişir, rakip yeni bir özellik çıkarır.

Sonuç olarak şelale ekibi aylarca çalışır ve ürünü ancak sonunda gösterir. Bu noktada yanlış anlaşılan bir gereksinimi düzeltmek pahalıya patlar. Benim sahada gördüğüm en yaygın tablo şudur: sözleşmedeki kapsam tamamlanır ama kullanıcının asıl ihtiyacı karşılanmaz. Kısacası sorun planın kendisinde değil, belirsizliği yok sayan varsayımdadır.

Öte yandan şelalenin tamamen yanlış olduğunu söylemiyorum. Kapsamı yasayla sabit olan, değişmeyecek işlerde hâlâ işe yarar. Yine de çoğu web ve mobil ürün bu kategoriye girmez.

Agile yaklaşımın cevabı basittir: belirsizliği ortadan kaldıramıyorsanız onu küçük parçalara bölün. İşi kısa döngülerle teslim eder, her döngünün sonunda gerçek kullanıcıdan ya da müşteriden geri bildirim alırsınız. Böylece yanlış bir varsayım aylar sonra değil, birkaç hafta içinde ortaya çıkar. Üstelik düzeltme maliyeti de o oranda küçük kalır.

Bu yazının geri kalanında önce Agile felsefesini, ardından Scrum çerçevesinin rollerini, etkinliklerini ve çıktılarını anlatacağım. Son bölümlerde Kanban farkına, hibrit modellere ve sahada en sık gördüğüm hatalara geçeceğim. Her başlıkta resmi rehberin ne dediğini ve benim pratikte ne gözlemlediğimi ayrı ayrı belirtmeye özen gösterdim; böylece hangisinin kural, hangisinin tavsiye olduğunu kolayca ayırt edersiniz.

Agile Manifesto hangi dört değeri savunur?

Agile Manifesto 2001 yılında Utah'ta bir araya gelen on yedi yazılımcının imzasıyla yayımlandı. Metnin resmi Türkçe çevirisi dört değer cümlesi içerir. Bu cümleler soldakini sağdakinden daha değerli bulur; sağdakini tamamen reddetmez:

• Süreçler ve araçlar yerine bireyler ve etkileşimler.
• Kapsamlı dokümantasyon yerine çalışan yazılım.
• Sözleşme pazarlığı yerine müşteri ile iş birliği.
• Bir plana bağlı kalmak yerine değişime karşılık vermek.

Dikkat ederseniz manifesto bir yöntem değildir. Size toplantı takvimi ya da rol tanımı vermez. Bu yüzden "Agile uyguluyoruz" diyen bir ekibe her zaman şu soruyu sorarım: hangi çerçeveyle? Cevap genellikle Scrum, Kanban ya da ikisinin karışımıdır.

Agile'ın 12 ilkesi günlük işe nasıl yansır?

Manifestonun arkasında on iki ilke yer alır. Hepsini ezberlemenize gerek yok; ancak birkaçı günlük işi doğrudan şekillendirir. Örneğin ilk ilke, değerli yazılımı erken ve sürekli teslim ederek müşteriyi memnun etmeyi öne koyar. Başka bir ilke çalışan yazılımı ilerlemenin birincil ölçüsü sayar.

• Birkaç haftadan birkaç aya uzanan aralıklarla, tercihen kısa olanla, çalışan yazılım teslim edin.
• İş birimleri ve geliştiriciler proje boyunca her gün birlikte çalışsın.
• Yüz yüze konuşmayı bilgi aktarmanın en etkili yolu sayın.
• Sadeliği, yani yapılmayan işi en çoğa çıkarma sanatını önemseyin.
• Ekip düzenli aralıklarla nasıl daha etkili olacağını düşünsün ve davranışını ayarlasın.

Bu ilkelerden özellikle sadelik maddesini seviyorum. Çünkü müşteri projelerinde en çok zaman kaybettiren şey, kimsenin kullanmayacağı özellikleri inşa etmektir. Dolayısıyla iyi bir Agile ekibi önce "bunu yapmasak ne olur?" diye sorar.

Scrum nedir ve Scrum Guide onu nasıl tanımlar?

Scrum Guide, Ken Schwaber ve Jeff Sutherland tarafından yazılan ve Scrum'ın tek resmi tanımını içeren kısa bir belgedir. Rehber Scrum'ı, karmaşık problemler için uyarlanabilir çözümlerle değer üreten hafif bir çerçeve olarak tanımlar. Yani Scrum eksiksiz bir süreç değildir; boşlukları ekip kendi pratikleriyle doldurur.

Scrum deneycilik (empirizm) ve yalın düşünce üzerine kuruludur. Deneycilik, bilginin deneyimden geldiğini ve kararları gözlemlenen gerçeğe göre verdiğinizi söyler. Yalın düşünce ise israfı azaltmaya ve esasa odaklanmaya çağırır. Bu iki kök, yazılım proje yönetimi pratiğinde tahmine değil kanıta dayanan bir çalışma biçimi doğurur.

Rehberin 2020 sürümü öncekilere göre daha az talimat içerir. Örneğin "Development Team" ifadesi yerine artık "Developers" kullanılır ve ekip "kendi kendini yöneten" olarak tarif edilir. Ayrıca rehber, Scrum'ın yalnız yazılım için değil her türlü karmaşık iş için kullanılabileceğini vurgular.

Scrum'ın üç sütunu ve beş değeri nelerdir?

Scrum Guide deneyciliği üç sütuna dayandırır: şeffaflık, denetleme ve uyarlama. Şeffaflık, işi yapanların ve işten etkilenenlerin süreci görebilmesidir. Denetleme, çıktıları ve hedefe ilerlemeyi sık kontrol etmektir. Uyarlama ise bir sapma gördüğünüzde süreci ya da ürünü hemen ayarlamaktır.

Bunlara ek olarak rehber beş değer sayar: bağlılık, odak, açıklık, saygı ve cesaret. Kâğıt üzerinde soyut görünürler. Pratikte ise çok somut sonuçları vardır. Örneğin cesaret, zor bir problemi sprint ortasında dile getirmek demektir. Açıklık da "bu işi yetiştiremeyeceğiz" cümlesini erken kurabilmektir.

Sahada gözlemim şu: değerleri duvara asan ama toplantıda kötü haberi saklayan ekipler, Scrum'ın sadece takvimini uygular. Bu nedenle bir ekibin olgunluğunu seremonilerden çok, sorunları ne kadar erken konuştuğundan anlarsınız.

Scrum ekibinde hangi roller vardır ve her biri neden sorumludur?

Scrum Guide üç sorumluluk (accountability) tanımlar. Rehbere göre bir Scrum ekibi tipik olarak on ya da daha az kişiden oluşur; küçük ekipler daha iyi iletişim kurar. Ekipte alt ekip ya da hiyerarşi yoktur.

Tablodaki ayrım bana göre en kritik noktadır. Çünkü birçok şirkette Product Owner rolü bir ara iletişim görevlisine dönüşür. Oysa rehber, Product Owner'ın tek kişi olduğunu ve kararlarına saygı duyulması gerektiğini açıkça yazar.

Product Owner ile proje yöneticisi aynı kişi midir?

Hayır, aynı rol değildir. Klasik proje yöneticisi kapsamı, zamanı ve bütçeyi kontrol eder; ekibe iş dağıtır. Scrum'da ise iş dağıtan kimse yoktur. Developers işi kendi aralarında planlar. Product Owner "ne" ve "neden" sorusuna cevap verir, "nasıl" kısmına karışmaz.

Dolayısıyla eski bir proje yöneticisini doğrudan Product Owner yapmak riskli olabilir. Bu kişinin iş birimini ve müşteriyi tanıması, önceliklendirme kararı alabilmesi gerekir. Öte yandan Scrum Master rolü de bir yönetici koltuğu değildir; ekibe hizmet eden bir liderlik biçimidir.

Müşteri tarafında da benzer bir durum yaşarım. Bir web projesinde karar verici belirsizse, sprint sonunda gösterilen işe beş farklı kişiden beş farklı yorum gelir. Kısacası ben projeye başlarken ilk olarak "son sözü kim söyleyecek?" sorusunu netleştiririm.

Sprint nedir ve neden bir aydan kısa tutulur?

Sprint, Scrum'ın kalbidir. Scrum Guide'a göre sprint sabit uzunlukta, bir ay ya da daha kısa süren bir döngüdür. Bir sprint biter bitmez yenisi başlar. Diğer tüm etkinlikler sprintin içinde gerçekleşir.

Neden kısa tutarsınız? Çünkü sprint uzadıkça Sprint Hedefi geçersiz kalabilir, karmaşıklık artar ve risk büyür. Kısa döngü, ekibe en geç ayda bir gerçek geri bildirim almayı garanti eder. Ayrıca sprint sırasında Sprint Hedefini tehlikeye atacak değişiklik yapmazsınız ve kalite hedeflerini düşürmezsiniz.

Pratikte iki haftalık sprintler çok yaygındır; ancak rehber belirli bir uzunluk dayatmaz. Takvim hesabı yaparken sprint sonlarını ve tatilleri görmek için gün hesaplama aracını kullanabilirsiniz. Böylece bayram haftasına denk gelen bir sprint incelemesini önceden fark edersiniz.

Sprint Planning toplantısında hangi sorular cevaplanır?

Sprint Planning sprintin ilk etkinliğidir. Rehbere göre bir aylık sprint için en fazla sekiz saat sürer; kısa sprintlerde genellikle daha kısadır. Toplantı üç konuyu ele alır:

1. Bu sprint neden değerli? Product Owner değeri anlatır, ekip birlikte bir Sprint Hedefi belirler.
2. Bu sprintte ne yapılabilir? Developers, Product Backlog'dan seçtikleri öğeleri geçmiş performanslarına ve kapasitelerine göre belirler.
3. Seçilen iş nasıl bitecek? Developers her öğeyi genellikle bir günlük ya da daha küçük parçalara böler.

Bu üç sorunun sonucunda Sprint Backlog ortaya çıkar. Benim önerim şu: Sprint Hedefini tek cümleyle yazın. Örneğin "Kullanıcı sepetten ödeme sayfasına hatasız geçebilsin" gibi. Böylece sprint ortasında gelen her talebi bu cümleyle karşılaştırırsınız.

Daily Scrum 15 dakikada nasıl verimli yönetilir?

Daily Scrum, Developers için her gün aynı saatte ve aynı yerde yapılan 15 dakikalık bir etkinliktir. Amacı Sprint Hedefine ilerlemeyi denetlemek ve gerekirse Sprint Backlog'u uyarlamaktır. Bu bir durum raporu toplantısı değildir.

Eski rehber sürümlerindeki "dün ne yaptım, bugün ne yapacağım, engelim ne" kalıbı 2020 sürümünde zorunlu değildir. Ekip, hedefe odaklandığı sürece istediği yapıyı seçer. Üstelik ayrıntılı teknik tartışmayı toplantı sonrasına bırakmak zaman kazandırır.

• Toplantıyı panonun önünde, işin kendisi üzerinden yürütün.
• Sprint Hedefine en uzak işi ilk sırada konuşun.
• Bir engel çıktığında çözümü değil, çözecek kişiyi belirleyin.
• Yöneticinin katılımı bir rapor seansına dönüşüyorsa bunu açıkça konuşun.

Kısacası 15 dakikayı aşan her Daily Scrum, bir şeyin yanlış planlandığını işaret eder. Bu durumda toplantıyı uzatmak yerine, sorunu çözmesi gereken iki ya da üç kişiyle hemen ardından kısa bir çalışma oturumu açmanızı öneririm. Böylece ekibin geri kalanı işine döner.

Sprint Review ile Sprint Retrospective arasındaki fark nedir?

İki toplantı da sprintin sonunda yer alır, ancak farklı şeyleri denetler. Sprint Review ürünü, Sprint Retrospective ise çalışma biçimini inceler. Rehbere göre bir aylık sprint için Review en fazla dört saat, Retrospective ise en fazla üç saat sürer.

Sprint Review bir sunum değil, çalışma oturumudur. Ekip ne ürettiğini paydaşlara gösterir; paydaşlar geri bildirim verir ve birlikte Product Backlog'u günceller. Web projelerinde bu toplantıda gerçek ekranları, hatta canlı test ortamını açarım. Böylece müşteri ürünü slayttan değil ekrandan görür.

Retrospective ise ekip içidir. Kişiler, etkileşimler, süreçler, araçlar ve Definition of Done ele alınır. Ekip en faydalı iyileştirmeleri seçer ve mümkünse bir sonraki sprintin Sprint Backlog'una ekler. Aksi takdirde iyileştirme kararları not defterinde kalır ve her retrospektifte aynı şikâyet tekrar eder.

Scrum'ın üç çıktısı ve taahhütleri neyi güvenceye alır?

Scrum Guide üç çıktı (artifact) tanımlar ve her birine bir taahhüt bağlar. Bu taahhütler şeffaflığı ve odağı güçlendirir. Aşağıdaki tablo ilişkiyi özetliyor.

Burada en çok hafife alınan kavram Definition of Done'dır. Rehbere göre bir öğe bu tanımı karşılamıyorsa artımın parçası olamaz ve sunulamaz. Web projelerinde benim Bitti Tanımım genellikle mobil test, hız kontrolü, erişilebilirlik ve temel SEO kontrollerini içerir. Örneğin meta etiketleri meta tag oluşturucu ile kontrol etmeden bir sayfayı bitmiş saymam.

Product Backlog nasıl sıralanır ve iyileştirilir?

Product Backlog, ürünü geliştirmek için gereken her şeyin sıralı listesidir. Sıralamadan Product Owner sorumludur. Ancak listeyi tek başına yazmak zorunda değildir; ekipten ve paydaşlardan girdi alır.

Backlog refinement, yani iyileştirme, öğeleri daha küçük ve daha net parçalara bölme işidir. Bu sırada açıklama, sıra ve büyüklük eklersiniz. Rehber bunu ayrı bir etkinlik olarak tanımlamaz; sürekli devam eden bir faaliyet olarak anlatır. Yine de ekiplerin çoğu haftada bir kısa bir oturum ayırır.

Sıralama yaparken ben üç soruyu kullanırım: bu öğe ne kadar değer üretir, ne kadar risk azaltır ve başka bir işin önünü açıyor mu? Örneğin bir e-ticaret projesinde ödeme adımı, blog modülünden önce gelir. Çünkü ölçülebilir dönüşüm hedefi oradadır. Bu konuda dijital pazarlama KPI yazım önceliklendirme için iyi bir ölçüt seti sunar.

Kanban nedir ve Scrum'dan hangi noktalarda ayrılır?

Kanban, işin akışını görselleştiren ve devam eden iş miktarını (WIP) sınırlayan bir yöntemdir. Kanban Guide üç temel pratik sayar: akışı tanımlayıp görselleştirmek, iş öğelerinin akışını aktif yönetmek ve iş akışı tanımını iyileştirmek. Kanban'da sabit sprint, zorunlu rol ya da seremoni yoktur.

Kısacası Scrum ritim sağlar, Kanban akışı optimize eder. Bu yüzden ikisini rakip değil, farklı problemlere verilen cevaplar olarak görmek daha doğru olur.

WIP limiti neden ekibi hızlandırır?

İlk bakışta aynı anda daha az iş yapmak yavaşlamak gibi görünür. Ancak gerçekte tersi olur. Beş işe aynı anda başlayan bir geliştirici bağlam değiştirmek için sürekli zaman kaybeder ve hiçbir işi bitiremez. WIP limiti ise "yeni işe başlamadan önce mevcut işi bitir" kuralını görünür hale getirir.

Kanban Guide dört akış ölçüsünü öne çıkarır: devam eden iş (WIP), verim (throughput), iş yaşı (work item age) ve çevrim süresi (cycle time). Bu ölçüler tahmini değil, gerçekleşen akışı gösterir. Dolayısıyla "bu iş ne zaman biter?" sorusuna geçmiş veriye dayanarak cevap verirsiniz.

Kendi ekibimde en çok iş yaşına bakarım. Panoda bir kart günlerce aynı sütunda duruyorsa orada bir tıkanıklık vardır. Üstelik bu kartı Daily toplantıda ilk sıraya almak, sorunu büyümeden çözmeyi sağlar.

Scrumban ya da hibrit bir model ne zaman mantıklıdır?

Birçok ekip saf Scrum ya da saf Kanban kullanmaz. Sprint ritmini korurken panoya WIP limiti ekler. Bu karma yaklaşıma sahada genellikle Scrumban denir. Scrum.org ve Kanban topluluğu da iki yaklaşımın birlikte kullanılabileceğini ayrı rehberlerle anlatır.

• Ekip hem yeni özellik geliştiriyor hem de acil destek talebi alıyorsa.
• Sprint ortasında sürekli iş eklendiği için Sprint Hedefi sık bozuluyorsa.
• Ekip sprint sonunda çok sayıda yarım kalmış iş biriktiriyorsa.
• Bakım dönemine giren bir ürün artık büyük planlama toplantılarına ihtiyaç duymuyorsa.

Öte yandan hibrit model bir bahane olmamalı. "Bize özel bir Agile yapıyoruz" diyen ekiplerin bir kısmı aslında sadece retrospektifi atlamıştır. Bu yüzden hangi pratiği neden bıraktığınızı yazılı olarak kayda geçirmenizi öneririm.

Agile yazılım proje yönetimi uygularken en sık hangi hatalar yapılır?

Yıllar içinde gördüğüm hatalar birbirine çok benzer. Agile yazılım proje yönetimi ilkelerini kâğıtta benimseyip pratikte şelale gibi çalışmak bunların başında gelir. Aşağıda en sık karşılaştıklarımı sıraladım:

1. Sprint sonunda çalışan bir artım yerine sadece "yüzde 80 bitti" raporu sunmak.
2. Product Owner'ı karar yetkisi olmayan birine vermek.
3. Retrospektif kararlarını hiçbir sprinte eklememek.
4. Velocity değerini ekipler arası performans karşılaştırması için kullanmak.
5. Definition of Done'u yazmadan işe başlamak.
6. Daily Scrum'ı yöneticiye rapor verme toplantısına çevirmek.

Bu listedeki dördüncü madde özellikle zararlıdır. Çünkü ekipler tahmin puanlarını şişirmeye başlar ve ölçü anlamını yitirir. Kısacası metrik bir öğrenme aracıdır, bir cezalandırma aracı değildir.

Bir ajans ya da müşteri projesinde Scrum nasıl uyarlanır?

Müşteri projeleri iç ürün ekiplerinden farklıdır; çünkü sabit bütçe ve teslim tarihi çoğu zaman sözleşmede yazılıdır. Yine de Scrum'ın ruhunu korumak mümkündür. Ben web tasarım projelerinde kapsamı sabitlemek yerine önceliği sabitlerim. Yani en değerli sayfalar ve akışlar ilk sprintlerde biter.

Her sprint sonunda müşteriye canlı bir test ortamı gösteririm. Böylece müşteri tasarım dosyasını değil, çalışan sayfayı değerlendirir. Tasarım aşamasını Figma ile arayüz tasarımı sürecine bağlarım; geliştirme ise onaylanmış ekranlardan beslenir.

Ayrıca kapsam değişikliği geldiğinde kavga etmem. Bunun yerine müşteriye yeni işin backlog'da hangi öğenin yerini alacağını sorarım. Dolayısıyla bütçe sabit kalır, öncelik değişir. Bu yaklaşım sözleşme pazarlığı yerine müşteri ile iş birliği değerinin sahadaki karşılığıdır.

Ekip büyüdüğünde Scrum nasıl ölçeklenir?

Scrum Guide, ekip çok büyüdüğünde onu aynı ürüne odaklanan birden çok uyumlu Scrum ekibine bölmeyi önerir. Bu ekipler aynı Product Goal, aynı Product Backlog ve aynı Product Owner'ı paylaşır. Bunun ötesindeki ölçekleme çerçeveleri (Nexus, LeSS, SAFe gibi) rehberin kapsamı dışında kalır.

Büyük kurumsal sitelerde ekip bölünmesi mimariyi de etkiler. Her ekibin bağımsız teslim yapabilmesi için kod tabanının da bölünebilir olması gerekir. Bu konuyu micro frontend mimarisi yazımda ayrıntılı anlattım. Ekip yapısı ile yazılım mimarisi birbirini aynalar; bu yüzden ikisini birlikte planlamak gerekir.

Benim tavsiyem şu: ölçekleme çerçevesi seçmeden önce tek bir ekibin gerçekten iyi çalıştığından emin olun. Aksi takdirde karmaşayı sadece daha büyük bir tabloya taşırsınız.

Agile ekibinizin başarısını hangi göstergelerle ölçmelisiniz?

Başarıyı ölçmek için tek bir sayı yeterli olmaz. Scrum tarafında Sprint Hedeflerine ulaşma oranı ve düzenli olarak kullanılabilir artım üretmek temel göstergedir. Kanban tarafında ise çevrim süresi ve verim trendi öne çıkar. Ancak bunların hepsi süreç ölçüsüdür.

Asıl soru, teslim edilen yazılımın iş sonucuna katkısıdır. Örneğin yeni ödeme akışı dönüşüm oranını değiştirdi mi? Bu yüzden ekip panosunu iş göstergeleriyle bağlamanızı öneririm. Dönüşüm odaklı web tasarım yazım bu bağlantıyı kurmak için iyi bir başlangıçtır.

• Süreç ölçüsü: Sprint Hedefine ulaşma, çevrim süresi, iş yaşı.
• Kalite ölçüsü: canlıya çıkan hata sayısı, geri alınan sürümler.
• Değer ölçüsü: dönüşüm, kullanıcı memnuniyeti, destek talebi azalması.

Kısacası süreç ölçüsü iyi, değer ölçüsü kötüyse ekip hızlı koşuyor ama yanlış yöne gidiyor demektir.

User story ve story point Scrum'da zorunlu mu?

Hayır, ikisi de Scrum Guide'da geçmez. User story, bir ihtiyacı kullanıcının gözünden anlatan kısa bir cümle kalıbıdır: "Bir müşteri olarak siparişimi takip etmek istiyorum ki teslim tarihini bileyim." Story point ise bir işin göreli büyüklüğünü tahmin etmek için kullanılan birimdir. Her ikisi de ekiplerin sık seçtiği tamamlayıcı pratiklerdir.

Bu ayrımı bilmek önemlidir. Çünkü bazı ekipler story point tartışmasına Sprint Planning'in yarısını harcar ve bunu Scrum'ın gereği sanır. Oysa rehber yalnızca Product Backlog öğelerinin bir büyüklük bilgisi taşımasını ister; bunu nasıl ölçeceğinize ekip karar verir. Tişört bedenleri, gün tahmini ya da hiç tahmin yapmadan iş sayısı saymak da geçerli seçeneklerdir.

Benim önerim şu: tahmini bir pazarlık aracına dönüştürmeyin. Tahminin amacı, ekibin bir sprintte gerçekçi olarak neyi bitirebileceğini görmesidir. Ayrıca user story yazarken kabul kriterlerini de ekleyin. Böylece "bitti mi, bitmedi mi" tartışması sprint incelemesinde değil, planlamada çözülür.

Uzaktan çalışan ekipler Scrum etkinliklerini nasıl uygular?

Scrum Guide etkinliklerin yüz yüze olmasını şart koşmaz. Bu yüzden dağıtık ekipler de aynı çerçeveyi kullanır. Ancak uzaktan çalışmada şeffaflık kendiliğinden oluşmaz; onu bilinçli olarak kurmanız gerekir. Ortak bir dijital pano, yazılı Sprint Hedefi ve kayıt altına alınan kararlar bu noktada temel ihtiyaçtır.

• Daily Scrum'ı farklı saat dilimlerinin kesiştiği sabit bir saate koyun.
• Sprint Review'da ekran paylaşımıyla canlı ürünü gösterin, slayt kullanmayın.
• Retrospektifte anonim not alanı açın; çekingen üyeler de söz alsın.
• Kararları sohbet mesajında bırakmayın, backlog öğesinin içine yazın.

Kendi projelerimde müşteriler çoğu zaman farklı şehirlerde olur. Dolayısıyla sprint incelemesini kısa bir görüntülü görüşme ve ardından yazılı bir özetle kapatırım. Böylece toplantıya katılamayan paydaş da aynı bilgiye ulaşır.

Yazılım proje yönetimi için Scrum ile başlamak isteyen bir ekip ilk adımı nasıl atmalı?

Yazılım proje yönetimi dönüşümüne büyük bir eğitim programıyla başlamanıza gerek yok. Önce Scrum Guide'ı ekipçe okuyun; yaklaşık yirmi sayfalık kısa bir belgedir. Ardından küçük bir adımla ilerleyin:

1. Ürün için bir Product Owner belirleyin ve karar yetkisini yazılı hale getirin.
2. İlk Product Backlog'u sıralayın, en üstteki öğeleri küçük parçalara bölün.
3. Definition of Done'u bir sayfada yazın.
4. İki haftalık bir sprint ile başlayın ve tüm etkinlikleri eksiksiz uygulayın.
5. Üç sprint sonra retrospektifte neyi değiştireceğinize karar verin.

Bu sırada araç seçimine takılmayın; ilk sprinti bir duvar panosu ile bile yönetebilirsiniz. Diğer yazılım yazılarım için yazılım kategorisine göz atabilirsiniz. Projenizde bir ekip ve süreç kurulumu için destek isterseniz iletişim sayfasından bana yazabilirsiniz.