Sprint planlamasında sık yaşanan bir an vardır: ekip bir işe puan vermeye çalışır, biri "3" der, biri "13" der, üçüncüsü "bilmiyorum, IFS'in API'si bunu destekliyor mu ki?" diye sorar. Toplantı yirmi dakika uzar, sonunda orta bir sayı yazılır. O sayı bir tahmin değil, tahmin kılığına girmiş bir belirsizliktir.
Spike, bu durumun çevik yöntemlerdeki cevabıdır: tahmin edilemeyen işi tahmin etmeye zorlamak yerine, önce onu tahmin edilebilir yapacak bilgiyi toplamak için süresi baştan sınırlanmış bir çalışma yapılır.
Spike nedir?
Terim Extreme Programming (XP) kökenlidir; spike solution, bir problemin içinden hızlıca bir çivi geçirip öbür tarafta ne olduğunu görmek anlamında kullanılır. Scrum Rehberi'nde spike diye bir kavram geçmez, ama Scrum ekipleri bunu backlog'daki özel bir iş türü olarak yaygın biçimde kullanır.
Bir spike'ı sıradan bir kullanıcı hikâyesinden ayıran üç şey vardır:
| Kullanıcı hikâyesi | Spike | |
|---|---|---|
| Çıktısı | Çalışan, kullanıcıya değer veren yazılım | Bilgi: bir karar, bir tahmin, bir bulgu |
| Süresi | Tahmine göre | Baştan sabit (zaman kutusu) |
| Bittiğinde | Canlıya gidebilir | Kodu genellikle atılır; canlıya gitmez |
Kısacası spike bir soruyu cevaplar. Yazılım üretmez; yazılımın nasıl üretileceğine karar verdirir.
İki tür spike
- Teknik spike. Bir teknik belirsizliği giderir: entegrasyon mümkün mü, performans yeterli mi, bu kütüphane işimizi görür mü, mimari seçeneklerden hangisi uygun?
- Fonksiyonel spike. Bir iş belirsizliğini giderir: kullanıcı bu akışı nasıl bekliyor, iş kuralı hangi durumda istisna üretiyor, ekran tek adımda mı yoksa sihirbaz olarak mı çalışmalı? Genellikle hızlı bir prototip ya da kullanıcıyla kısa bir oturumla yapılır.
İyi bir spike'ın anatomisi
Kötü yazılmış spike: "IFS entegrasyonunu araştır." Bu bir iş değil, bir konu başlığıdır; ne zaman biteceği belli değildir.
İyi yazılmış spike dört parçadan oluşur:
Soru : IFS REST API üzerinden müşteri siparişi satırı
oluşturup aynı çağrıda rezervasyon yapabiliyor muyuz?
Zaman kutusu : 2 gün
Çıktı : Evet/Hayır + çalışan örnek çağrı + kısıtların listesi
Sonraki adım : Cevaba göre "Sipariş aktarımı" hikâyesi yeniden tahmin edilecek- Tek bir soru. Cevabı evet/hayır ya da bir sayı olabilecek kadar dar. Soru iki taneyse spike da iki tanedir.
- Zaman kutusu. Genellikle birkaç saat ile birkaç gün arası, tek sprint içinde. Süre dolduğunda spike biter — cevap bulunmuş olsun ya da olmasın. Bulunamadıysa bu da bir bulgudur.
- Tanımlı çıktı. Ne teslim edilecek? Bir karar notu, bir ölçüm sonucu, çalışan bir deneme kodu, bir tahmin.
- Sonraki adım. Spike'ın sonucu hangi hikâyeyi, hangi kararı besleyecek? Bağlandığı bir iş yoksa o spike muhtemelen gereksizdir.
Bu dört parça, aslında CTQ notunda anlattığımız mantığın küçük ölçekli hâlidir: "araştıralım" isteğini ölçülebilir bir kabul kriterine çevirmek.
ERP projelerinden örnekler
| Belirsizlik | Spike sorusu | Zaman kutusu |
|---|---|---|
| Entegrasyon | E-fatura entegratörünün API'si toplu gönderimi ve durum sorgulamayı destekliyor mu? | 1 gün |
| Performans | 2 milyon satırlık stok hareketi üzerinde aylık rapor 3 saniyenin altına iner mi? | 2 gün |
| Veri kalitesi | Eski sistemdeki cari kartların yüzde kaçı vergi numarasıyla eşleşiyor? | 1 gün |
| Teknoloji | SOLIDWORKS API ile montajdaki her parçanın malzeme ve kütle bilgisi okunabiliyor mu? | 2 gün |
| Kullanıcı akışı | Depo personeli sayımı el terminalinde tek ekranda yapabilir mi, yoksa iki adım mı gerekir? | yarım gün + saha denemesi |
Performans spike'larında ilk bakılacak yerleri Oracle performans kontrol listemizde topladık; iki günlük bir spike'ın ilk yarım günü genellikle o listeyle geçer.
Scrum akışında spike
- Backlog'a girer. Bir hikâye tahmin edilemediğinde ya da iyileştirme sırasında belirsizlik ortaya çıktığında Product Owner ve ekip spike'ı ayrı bir iş olarak ekler.
- Sprint planlamasında zaman kutusu alır. Puan verilip verilmeyeceği ekipten ekibe değişir: bazı ekipler spike'a puan vermez ve kapasiteden düşer, bazıları zaman kutusuna denk gelen puanı yazar. Önemli olan tutarlılıktır; hız (velocity) hesabında spike'ların nasıl sayıldığı ekipçe bilinmelidir.
- Sprint içinde yapılır. Zaman kutusu dolduğunda durulur. "Biraz daha bakalım" diye uzatmak, spike'ı spike olmaktan çıkarır.
- Sprint Review'da bulgu gösterilir. Çıktı bir yazılım olmadığı için gösterilen şey karardır: "Evet yapılabiliyor, şu kısıtla" ya da "Hayır, alternatif şu."
- Sonuç backlog'a döner. Asıl hikâye yeniden tahmin edilir, bölünür ya da tamamen vazgeçilir.
Nerede tökezleniyor?
- Soru yazılmaz. "Araştır" diye açılan spike'ın bitişi yoktur. Zaman kutusu dolar, ekip "biraz daha anladık" der ama hiçbir karar çıkmaz.
- Zaman kutusu esner. İki günlük spike bir sprinte yayılır. Belirsizliği azaltmak için açılan iş, belirsizliğin kendisine dönüşür.
- Deneme kodu canlıya gider. Hızlı ve kirli yazılmış prototip "zaten çalışıyor" denerek ürüne alınır. Spike kodu öğrenmek için yazılır; üretim kalitesinde değildir ve öyle kalmalıdır.
- Her belirsizlik spike'a çevrilir. Sprint'in yarısı spike olursa ekip değer üretmiyor, sürekli hazırlık yapıyor demektir. Küçük belirsizlikler hikâyenin içinde çözülür; spike yalnızca tahmini gerçekten imkânsız kılan belirsizlik içindir.
- Sonuç yazılmaz. Bulgu bir kişinin kafasında kalır. Üç ay sonra aynı soru yeniden sorulur ve aynı spike yeniden açılır.
DMADV ve spike
İki yaklaşım farklı dünyalardan gelir ama aynı ihtiyaca cevap verir. DMADV'nin Analyze adımında alternatifler karşılaştırılırken, "bu alternatif gerçekten çalışır mı?" sorusu çıktığında cevap çoğu zaman bir spike'tır. Design adımında erken prototip çıkarma alışkanlığı da spike'ın fonksiyonel türüyle örtüşür.
Fark şudur: DMADV bir süreci baştan sona kurmanın haritasıdır, spike ise o haritada tek bir bilinmeyen noktayı aydınlatmanın aracıdır.
Biz nasıl kullanıyoruz
ERP projelerinde spike'ı en çok iki yerde kullanıyoruz: entegrasyonlarda, çünkü karşı sistemin API'sinin belgelerde yazdığı gibi davranıp davranmadığı ancak denenerek anlaşılır; ve özel ekran/uygulama geliştirmede, çünkü kullanıcının iş akışı ancak önüne bir şey konduğunda netleşir.
Entegrasyon belirsizliklerini Entegrasyon Stüdyosu çalışmalarında, ekran ve akış belirsizliklerini özel uygulama geliştirme sürecinde spike ile kapatıyor, sprint planını ERP Proje Yöneticiliği çatısı altında bu bulgulara göre kuruyoruz.