1

2

Siperden

Scrum ve XP

Biz Nasıl Yapıyoruz?

3

Contents .................................................................................................................................................... 1

Çevirenin Önsözü ...................................................................................................................... 8

Bilgilendirme ............................................................................................................................ 9

Jeff Sutherland’in Önsözü ........................................................................................................ 10

Mike Cohn’un Önsözü ............................................................................................................. 12

Önsöz: Scrum işe yaradı! ......................................................................................................... 13

İkinci Basımın Önsözü.............................................................................................................. 14

Bölüm ........................................................................................................................................ 15

Bir ............................................................................................................................................. 15

Giriş ....................................................................................................................................... 15

Açıklama ................................................................................................................................ 16

Neden Yazdım? ....................................................................................................................... 16

Ama Scrum Ne ki? ................................................................................................................... 17

Bölüm ........................................................................................................................................ 18

İki .............................................................................................................................................. 18

Ürün İş Listesi’ni nasıl oluştururuz? .......................................................................................... 18

Ürün İş Listesi’ndeki Diğer Alanlar ............................................................................................ 20

Ürün İş Listesi’ni İş Birimine(Müşteriye) Anlamlı Gelecek Seviyede Tutma .................................. 21

Bölüm ........................................................................................................................................ 22

Üç.............................................................................................................................................. 22

Sprint Planlama’ya Nasıl Hazırlanıyoruz? .................................................................................. 22

Bölüm ........................................................................................................................................ 24

Dört ........................................................................................................................................... 24

Sprint Planlama’yı Nasıl Yapıyoruz? .......................................................................................... 24

Ürün Sahibi Neden Katılmak Zorunda? ..................................................................................... 25

Kalitenin Neden Pazarlığı Olmaz? ............................................................................................. 26

Bitmeyen Sprint Planlama Toplantıları! .................................................................................... 28

Sprint Planlama Toplantısı’nın Yapısı ........................................................................................ 29

Sprint Uzunluğunu Belirleme ................................................................................................... 30

Sprint Hedefi’ni Belirleme........................................................................................................ 31

Sprint’e Hangi İşlerin Alınacağını Belirleme ............................................................................... 32

Sprint’e Hangi İşlerin Alınacağı Konusunda Ürün Sahibi’nin Etkisi Nedir? .................................... 33

Sprint’e Hangi İşlerin Alınacağına Geliştirme Takımı Nasıl Karar Verir?........................................ 34

İçgüdüsel Karar Verme ............................................................................................................ 34

Geliştirme Takımı’nın Hızını Hesaplama .................................................................................... 35

4

İşlerin Büyüklüğünü Belirlerken Hangi Tekniği Kullanıyoruz? ...................................................... 39

İndeks Kartlarını Neden Kullanıyoruz? ...................................................................................... 40

Bitti Tanımı ............................................................................................................................. 44

Planlama Poker ile Efor Tahmini............................................................................................... 44

Kullanıcı Hikayelerini Netleştirme............................................................................................. 47

Kullanıcı Hikayelerini Küçük Parçalara Bölme ............................................................................ 48

Kullanıcı Hikayelerini İşlere Bölme............................................................................................ 49

Günlük Scrum için Yer ve Zaman Belirleme ............................................................................... 51

Çizgiyi Nereye Çekmeliyiz?....................................................................................................... 51

Teknik Kullanıcı Hikayeleri ....................................................................................................... 52

Hata Takip Sistemi mi? Ürün İş Listesi mi? ................................................................................ 55

Sprint Planlama Toplantısı Sonunda Biter ................................................................................. 56

Bölüm ........................................................................................................................................ 57

Beş ............................................................................................................................................ 57

İletişimi Nasıl Gerçekleştiriyoruz?............................................................................................. 57

Bölüm ........................................................................................................................................ 59

Altı ............................................................................................................................................ 59

Sprint İş Listesi’ni Nasıl Oluştururuz? ........................................................................................ 59

Sprint İş Listesi’nin Formatı...................................................................................................... 59

Scrum Duvarı Nasıl Kullanılır? .................................................................................................. 61

Örnek 1: İlk Günlük Scrum’dan sonra ....................................................................................... 61

Örnek 2: Birkaç gün sonra........................................................................................................ 63

Burn-down Grafik Nasıl Oluşturulur? ........................................................................................ 64

Scrum Duvarı’nda Uyarı İşaretleri............................................................................................. 65

Takip Edilebilirlik? ................................................................................................................... 66

Tahminler Günlük mü, Saatlik mi Olmalı? ................................................................................. 67

Bölüm ........................................................................................................................................ 69

Yedi ........................................................................................................................................... 69

Takım Odasını Ayarlama .......................................................................................................... 69

Takım Beraber Otursun! .......................................................................................................... 70

Ürün Sahibi’ni Yakında Tutun ................................................................................................... 72

Müdürleri ve Koçları Yakında Tutun.......................................................................................... 72

Bölüm ........................................................................................................................................ 74

Sekiz .......................................................................................................................................... 74

Günlük Scrum’ları Nasıl Yapıyoruz? .......................................................................................... 74

Scrum Duvarı’nı Güncelleme.................................................................................................... 75

5

Geç Gelenlerle Başa Çıkma ...................................................................................................... 76

“Bugün Ne Yapacağımı Bilmiyorum”cularla Başa Çıkma ............................................................. 76

Bölüm ........................................................................................................................................ 79

Dokuz ........................................................................................................................................ 79

Sprint Demo’larını Nasıl Yapıyoruz?.......................................................................................... 79

Bütün Sprint’lerin Bir Demo’yla Bitmesinde Neden Israr Ediyoruz? ............................................ 79

Sprint Demo’lar için Kontrol Listesi........................................................................................... 80

Demosu Yapılamayacak İşler.................................................................................................... 81

Bölüm ........................................................................................................................................ 82

On ............................................................................................................................................. 82

Sprint Retrospektifleri Nasıl Yapıyoruz? .................................................................................... 82

Neden Bütün Takımların Retrospektif Yapması Konusunda Israr Ediyoruz? ................................. 82

Retrospektifleri Nasıl Organize Ederiz? ..................................................................................... 83

Takımlar Arası Bilgi Paylaşımı ................................................................................................... 85

Değişmeli ya da Değişmemeli .................................................................................................. 86

Retrospektifte Ortaya Çıkan Örnekler....................................................................................... 86

“Kullanıcı hikayelerini daha küçük kullanıcı hikayelerine ya da işlere bölmek için daha fazla zaman ayırmalıyız” ............................................................................................................................ 86

“Dikkat dağıtan şeyler”............................................................................................................ 87

“Sprint’e fazla iş alıyoruz ve aldıklarımızın yarısını bitirebiliyoruz” .............................................. 87

“Ofisimiz çok gürültülü ve dağınık”........................................................................................... 87

Bölüm ........................................................................................................................................ 89

Onbir ......................................................................................................................................... 89

Sprint’ler arasında boş zaman .................................................................................................. 89

Bölüm ........................................................................................................................................ 92

Oniki.......................................................................................................................................... 92

Teslim planlamasını ve sabit fiyat anlaşmalarını nasıl yapıyoruz?................................................ 92

Kabul Eşiklerinizi Belirleyin ...................................................................................................... 92

En Önemli İş Maddelerinin Zaman Tahmini............................................................................... 94

Takım Hızını Tahmin Etme ....................................................................................................... 95

Her Şeyi Teslim Planında Birleştirme ........................................................................................ 96

Teslim Planını Uyarlama .......................................................................................................... 98

Bölüm ........................................................................................................................................ 99

Onüç.......................................................................................................................................... 99

Scrum ve XP’yi Beraber Nasıl Kullanıyoruz?............................................................................... 99

Eşli Programlama .................................................................................................................... 99

6

Test Yönelimli Geliştirme(Test Driven Development)................................................................100

Yeni Projelerde TYG ...............................................................................................................102

Eski Projelerde TYG ................................................................................................................102

Artımlı Tasarım ......................................................................................................................103

Sürekli Entegrasyon ...............................................................................................................103

Ortak Kod Sahipliği.................................................................................................................104

Bilgilendirici Çalışma Alanı ......................................................................................................104

Kodlama Standartları .............................................................................................................105

Sürdürülebilir Hız / Enerjik İş...................................................................................................105

Bölüm .......................................................................................................................................107

Ondört......................................................................................................................................107

Nasıl Test Yapıyoruz? .............................................................................................................107

Muhtemelen Kabul Testi Aşamasından Kurtulamazsınız ...........................................................107

Kabul Testi Aşamasını En Aza İndirme .....................................................................................109

Testçileri Scrum Takımı’nın İçine Yerleştirerek Kaliteyi Artırma .................................................109

Testçi, Onay Veren Adam .......................................................................................................110

Test Yapılacak Bir şey Olmadığında Testçi Ne Yapar? ................................................................110

Sprint’te Daha Az İş Yaparak Kaliteyi Artırma ...........................................................................112

Kabul Testi Aşaması, Sprint’in Bir Parçası mıdır? ......................................................................112

Sprint Döngüleri mi, Kabul Testi Döngüleri mi? ........................................................................113

Yaklaşım 1: “Eski Kullanıcı Hikayelerini Üretim Ortamına Almadan Yeni Kullanıcı Hikayelerini Geliştirmeye Başlamayın” .......................................................................................................115

Yaklaşım 2: “Yeni Kullanıcı Hikayeleri Geliştirilebilir Fakat Eski Kullanıcı Hikayeleriyle Karşılaştırılıp Öncelikleri Belirlenmelidir” .....................................................................................................116

Kötü Yaklaşım: “Yeni Kullanıcı Hikayeleri Geliştirmeye Odaklanma” ..........................................116

Zincirinizdeki En Zayıf Halkayı Geçmeye Çalışmayın..................................................................117

Gerçeğe Dönüş ......................................................................................................................118

Bölüm .......................................................................................................................................119

Onbeş .......................................................................................................................................119

Birden Fazla Scrum Takımı’yla Nasıl Çalışıyoruz? ......................................................................119

Kaç Scrum Takımı oluşturulacak? ............................................................................................119

Sanal Takımlar .......................................................................................................................120

İdeal Takım Büyüklüğü ...........................................................................................................122

Sprint’ler Senkronize mi, Değil mi? ..........................................................................................123

Takım Lideri Rolü Neden Var? .................................................................................................124

Takımları Nasıl Belirleriz?........................................................................................................125

7

Uzmanlık Takımları mı? ..........................................................................................................126

Yaklaşım 1: Alanlarına Göre Uzman Takımlar ...........................................................................127

Yaklaşım 2: Çapraz Takımlar....................................................................................................128

Sprint’ler Arası Takımlar Yeniden Ayarlanmalı mı, Ayarlanmamalı mı?.......................................129

Yarı Zamanlı Takım Üyeleri .....................................................................................................130

Scrum’ların Scrum’ını Nasıl Yapıyoruz? ....................................................................................131

Ürün Seviyesinde Scrum’ların Scrum’ı .....................................................................................132

Şirket Seviyesinde Scrum’ların Scrum’ı ....................................................................................133

Günlük Scrum’ları Boş Geçme .................................................................................................134

Yangın Söndüren Takımlar ......................................................................................................135

Ürün İş Listesi’ni Bölmek ya da Bölmemek? .............................................................................137

Strateji 1: Bir Ürün Sahibi ve Bir Ürün İş Listesi.........................................................................137

Strateji 2: Bir Ürün Sahibi ve Birden Fazla Ürün İş Listesi...........................................................139

Strateji 3: Birden Fazla Ürün Sahibi ve Her Ürün Sahibi için Bir Ürün İş Listesi ............................140

Kod Branch’leme....................................................................................................................141

Birden Fazla Takımla Retrospektif ...........................................................................................142

Bölüm .......................................................................................................................................144

OnAltı .......................................................................................................................................144

Dağıtık Takımlarla Nasıl Çalıştık? .............................................................................................144

Üretimin Bazı Aşamalarının Ülke Dışında Gerçekleştirilmesi (Offshoring) ...................................145

Evden Çalışan Takım Üyeleri ...................................................................................................146

Bölüm .......................................................................................................................................148

OnYedi......................................................................................................................................148

Scrum Master Kontrol Listesi ..................................................................................................148

Sprint Başlangıcı ....................................................................................................................148

Her gün .................................................................................................................................148

Sprint Sonu............................................................................................................................149

Bölüm .......................................................................................................................................150

OnSekiz ....................................................................................................................................150

Son Sözler .............................................................................................................................150

Okuma Önerileri ....................................................................................................................151

Yazar Hakkında ......................................................................................................................152

8

Çevirenin Önsözü

“Kanban ve Scrum, İkisinin de En İyisini Yapmak”, “Siperden Yalınlık, Kanban ile Büyük Ölçekli

Projelerin Yönetimi” kitaplarından sonra Henrik’in bir başka kitabını çevirmek çok büyük bir zevkti.

Çeviklik, Yalınlık, Scrum, Kanban, eXtreme Programming(XP) konularında ne yazık ki Türkçe kaynak

sayısı yok denilecek kadar az! Bu açığın kapatılması gerektiğini düşünüyorum. Ülke olarak İngilizce

bilen kişi oranımız çok düşük. İnsanların bir konuyu öğrenebilmesi için ilk önce İngilizce öğrenmesi

gerekiyor. Gerekmemeli! Eğitim sistemimizde böyle büyük bir yanlış var! Tek başıma bu yanlışı

düzeltemem fakat bireysel çaba gösterebilirim. Bu büyük yanlışın yanında bireyler olarak bizimde

yanlışımız var. Birey olarak yaşıyoruz! Halbuki toplum olarak yaşamalıyız! Kendimiz için yaşıyoruz ve

kendimizin dışında hiçbir şey önemli değil!

Keşke herkes iyi bildiği bir konuda birkaç kitap yazabilse ya da çevirebilse, o zaman ülkemizin insanı

için bir şeylerin yolunu kolaylaştırmış oluruz.

Diğer kitaplara ulaşabileceğiniz adres: http://yilmazcihan.com/ceviri-kitaplarim

Cihan Yılmaz

Mart 2017 – İstanbul

site@yilmazcihan.com http://yilmazcihan.com

9

Bilgilendirme

Kitabın ilk halini sadece bir hafta sonunda yazdım. Elbette yoğun bir hafta sonuydu. %150 odaklanma

etkisi :)

Eşim Sophia, çocuklar Dave ve Jenny’ye o hafta sonu asosyalliğime katlandıkları için teşekkür ederim.

Ayrıca o hafta sonu bize gelen ve ailemle ilgilenen Sophia’nın annesi ve babası, Eva’ya ve Jörgen’e

teşekkür ederim.

Düzeltmelere ve kitabı iyileştirmeme yardım eden Crisp’teki iş arkadaşlarıma ve Scrum Users Yahoo

grubundaki kişilere teşekkür ederim.

Son olarak sürekli olarak geribildirimlerde bulunan bütün okuyucularıma teşekkür ederim. Çevik

yazılım geliştirmeye bu kitap aracılığıyla bir şans verdiğinizi duymaktan oldukça mutlu oldum.

10

Jeff Sutherland’in Önsözü

Takımlar, Scrum temellerini bilmelidir. Ürün İş Listesi nasıl oluşturulur ve Ürün İş Listesi’ndeki iş

maddelerinin büyüklük tahminleri nasıl yapılır? Ürün İş Listesi’ni, Sprint İş Listesi’ne nasıl

dönüştürürsünüz? Burn-down grafiği nasıl oluşturursunuz ve takımın hızını nasıl hesaplarsınız?

Henrik’in kitabı başlangıç için güzel bir seçimdir. Takımların nasıl iyi Scrum yapabileceğini anlatır.

Yatırım almak isteyen takımlar için Scrum’ı iyi yapmak daha önemli hale geliyor. Bir risk sermayesi

grubunun Çevik Koçu olarak, grubun, Çeviklik Pratikleri iyi yapan, Çevik şirketlere yatırım yapma

hedeflerine erişmelerinde yardımcı olurum. Yani çalıştığım yatırım şirketi, Çevik girişimcileri

destekler. Grubun büyük ortağının bütün şirketlere sorduğu soru şudur: “Takımınızın hızını biliyor

musunuz?” Şirketler, bu soruyu cevaplamakta zorlanıyorlar. Gelecekteki yatırım fırsatları, Geliştirme

Takımlarının, kendi -yazılım geliştirme- hızlarını bilmelerini gerektirecektir.

Bu neden çok önemli? Eğer takımlar hızlarını bilmiyorlarsa, Ürün Sahibi, güvenilir teslim tarihleri olan

bir ürün yol haritası oluşturamaz. Belirli olmayan teslim tarihleriyle, şirket batabilir ve yatırımcılar

para kaybedebilir.

Bu problemle büyük ya da küçük, eski ya da yeni, yatırım alan ya da almayan, tüm şirketler karşılaşır.

Londra’daki bir konferansta Google’ın Scrum uygulamaya başlamasını tartıştık. Konferansa kat ılan

135 kişiye kaçının Scrum uyguladığını sordum ve 30 kişi olumlu cevap verdi. Daha sonra Nokia

standartlarında artımlı geliştirme yapıp yapmadıklarını sordum. Artımlı geliştirme, Çevik Bildiri’nin

temelidir(Çalışan yazılımı erken ve sık sık teslim etmek). Yüzlerce Scrum takımının yıllardır yaptığı

retrospektiflerden sonra Nokia artımlı geliştirme için bazı standartlar geliştirdi:

İterasyonlar(döngüler), sabit bir süreye sahip olmalıdır ve altı haftadan kısa olmalıdır.

Döngü sonunda kod, kalite güvencesini(QA) sağlayan kişiler tarafından test edilmelidir ve çalışır

olmalıdır.

Scrum yaptığını söyleyen 30 kişiden sadece yarısı Nokia standartlarında Çevik Bildiri’nin birinci ilkesini

yapabildiklerini söylediler. Daha sonra Nokia standartlarını karşılayıp karşılamadıklarını sordum:

11

- Scrum Takımı’nın bir Ürün Sahibi olmalıdır ve Geliştirme Takımı bu kişinin kim olduğunu

bilmelidir.

- Ürün Sahibi, Ürün İş Listesi’ne sahip olmalıdır.

- Ürün İş Listesi’ndeki işlerin büyüklüğü Geliştirme Takımı tarafından belirlenmiş olmalıdır.

- Sprint içinde, Geliştirme Takımı dışından biri takımın işine karışmamalıdır.

Scrum yapan 30 kişiden sadece üçü yukarıdakileri karşılayabildiklerini söylediler. Çalıştığım yatırım

şirketinden sadece bu üç takım yatırım desteği alabilecektir.

Henrik’in kitabının değeri şudur; Henrik’in ana hatlarını belirlediği pratikleri takip ederseniz, Ürün İş

Listesi’ne, Ürün İş Listesi’ndeki maddelerin büyüklüklerine, burn-down grafiğe sahip olacaksınız,

birçok temel pratiğin yanında takımınızın hızını bi leceksiniz. Nokia standartlarında Scrum yapıyor ve

yatırım yapmaya değer olacaksınız. Eğer girişimci , küçük bir şirketseniz, büyük bir yatırım şirketinden

yatırım desteği bile alabilirsiniz. Belki yazılım geliştirmenin geleceği olacaksınız ve yazılım

geliştirmenin gelecek nesline liderlik ediyor olacaksınız.

Dr. Jeff Sutherland

12

Mike Cohn’un Önsözü

Scrum ve XP, ikisi de takımların döngü(iterasyon) sonunda çalışır kod teslim etmelerini gerekli kılar.

Bu döngüler, kısa ve süresi sabit döngülerdir. Kısa ve sabit bir sürede çalışan kodun teslim edilmesi,

Scrum ve XP takımlarının teoriler için zamanı olmadığı anlamına gelir. UML diyagramının mükemmel

olması, mükemmel ihtiyaç analiz dokümanı için çabalamazlar ya da hayal edilebilen tüm değişiklikleri

karşılayacak kodu yazmak için uğraşmazlar. Bunun yerine, Scrum ve XP takımları bir şeyleri bitirmeye

odaklanırlar. Bu takımlar, yol boyunca hatalar yapabileceklerini kabul ederler. Fakat aynı zamanda bu

hataları bulmanın yolunun teorik analiz ve tasarım seviyesinde olamayacağının farkındadırlar. Derine

dalarlar, ellerini kirletirler ve ürünü geliştirmeye başlarlar.

Bu kitabı diğerlerinden ayıran aynı motivasyondur. Bu motivasyon, işi teorikleştirme değil yapmaktır.

Henrik Kniberg’in bu odaklanmayı anladığı daha başından bellidir. Scrum’ın ne olduğuna dair uzun bir

açıklama yapmaz. Bu açıklama için bizi basit bir internet sitesine yönlendirir. Bunun yerine, takımının

Ürün İş Listesi’ni nasıl yönettiğini ve nasıl çalıştığını anlatır. Buradan başlayarak diğer bütün öğele rin

ve pratiklerin üzerinden geçer. Teori yok. Gönderme yok. Dipnot yok. Hiçbirine ihtiyaç yok. Henrik’in

kitabı Scrum’ın neden çalıştığını anlatan felsefi bir kitap değildir. Bu kitap, iyi çalışan Çevik bir takımı

anlatır.

Bu yüzden kitabın alt başlığı “Biz Nasıl Yapıyoruz”. Sizin Scrum yapış şekliniz farklı olabilir, bu,

Henrik’in Scrum yapış şeklidir. Başka bir takımın nasıl Scrum yaptığı bizim için neden önemli olsun

sorusunu sorabilirsiniz. Önemsemelisiniz çünkü diğerleri tarafından nasıl yapıldığını duyarak daha iyi

Scrum yapabilirsiniz, özellikle iyi yapanları dinlemelisiniz. En iyi Scrum yapış şekilleri diye bir liste yok

ve olmayacak. Çünkü takım ve proje şartları herkes için farklıdır ve bunlar diğer her şeyi gölgede

bırakır. En iyi pratikler yerine sadece iyi pratikleri ve bu pratiklerin hangi şartlar altında geliştirildiğini

bilmeye ihtiyacımız vardır. Başarılı takımların hikayelerini ve işlerini nasıl yaptıklarını yeterince

okuduktan sonra Scrum ve XP yaparken karşınıza çıkan engellere hazır ol acaksınız.

Henrik, iyi pratikleri ve içinde bulunduğu şartları anlatır ve bizim siperlerimizde nasıl daha iyi Scrum

ve XP yapabileceğimizi öğretir.

Mike Cohn,

Agile Estimating and Planning ve User Stories Applied for Agile Software Development yazarı.

13

Önsöz: Scrum işe yaradı!

Scrum işe yaradı, en azından bizim için(yani adından burada bahsetmeyeceğim Stockholm’deki bir

müşterim için). Umarım sizin de işinize yarar. Belki bu kitap size yardımcı olur.

Bir geliştirme metodolojisinin*(özür dilerim Ken, çerçevesinin) kitabına uygun şekilde yapılarak işe

yaradığını ilk defa gördüm. Tak ve çalıştır. Hepimiz (geliştiriciler, testçiler ve yöneticiler) mutluyuz.

Zor bir durumdan çıkmamıza yardımcı oldu. Pazardaki ciddi dalgalanma ve çalışan sayısının

azalmasına karşın odağı korumamızı sağladı.

Şaşırdığımı söylememem gerek fakat şaşırdım. Başlangıçta birkaç kitap bitirdikten sonra Scrum iyi

göründü ama neredeyse gerçek olacak kadar iyi göründü. Yani haklı olarak biraz şüpheciydim. Bir yıl

Scrum yaptıktan sonra takımdaki birçok kişi gibi ben de oldukça etkilendim. Bundan sonra

çalışacağım projelerde ilk tercihim Scrum olacak.

*Ken Schwaber, Scrum’ın yaratıcılarında biri, Scrum’ın bir metodoloji olmadığını, sınırları olan bir

çerçeve olduğunu söyler.

14

İkinci Basımın Önsözü

Sekiz yıl geçti ve bu kitap hala sevilen ve beğenilen bir kitap. Bu küçük kitabın yapacağı etkiyi hayal

dahi etmemiştim. Kitabı, Çevik yazılım geliştirme için birincil rehberleri olarak kullanan takımlarla,

yöneticilerle, koçlarla ve eğitmenlerle hala karşılaşıyorum.

Asıl konu 2007’den beri ben birçok şey öğrendim. Yani kitabın bir güncellemeye ihtiyacı var.

Kitap yayınlandığından beri Çeviklik ve Yalınlık konusunda uzman birçok düşünce lideriyle çalışma

şansı elde ettim, hatta bazıları akıl hocam oldu. Jeff Sutherland, Mary ve Tom Poppendieck, Jerry

Weinberg, Alistair Cockburn, Kent Beck, Ron Jeffries, ve Jeff Patton çok teşekkürler. Bundan daha iyi

danışman grubu hayal edemiyorum.

Ayrıca pratik hayatlarında bu fikirleri uygulamak isteyen birçok şi rkete yardımcı olma şansı elde

ettim. Bu şirketlerden bazıları krizdeydi bazılarıysa oldukça başarılı olan fakat daha iyi olmak isteyen

şirketlerdi. Sonuç olarak oldukça etkileyici bir maceraydı.

Bu eski kitabı yeniden okuduğumda birçok şeyin hala geçerli olduğunu görmek beni şaşırttı. Fakat

bazı sayfaları yırtıp atmak ve kendi kendime “Ne *&€# bir şey düşünüyordum? Siz böyle yapmayın,

daha iyi bir yolu var” demek istiyorum.

Kitap hayattan bir durum çalışması olduğuna göre hikayeyi değiştiremem. Ne olduysa oldu! Fakat

bunun üzerine yeni yorumlarda bulunabilirim.

Yani ikinci basımda bu yorumları göreceksiniz, tıpkı sinema filminde yönetmenin seçtikleri gibi. Kitabı

okurken omzunuzda benim olduğumu düşünün, bir şeylere yorum yapıyorum, sizi neşelendiriyorum.

Ayrıca çalıştığım şirketlerden bazı örneklerde vereceğim, çoğunlukla Spotify(bu aralar zamanımın

çoğu orada geçiyor) fakat başka şirketler de olacak.

Keyfini çıkarın!

Henrik, 2015 Mart

İşte yorumlarım böyle görünecek. Bu önsöz ve yorumlar hariç kitap ilk halindeki gibidir, değiştirilmemiş. Bu gölgeli kutular benim yorumlarım ve 8 yılda öğrendiklerimden yansıyanlardır.

15

Bölüm

Bir

Giriş

Organizasyonunuzda Scrum kullanmaya başlayacak olabilirsiniz ya da birkaç aydır Scrum yapıyor

olabilirsiniz. Scrum temelini anladınız, kitapları okudunuz ve belki de Scrum Master sertifikası bile

aldınız.

Tebrikler!

Fakat kafanız karışık.

Ken Schwaber’e göre Scrum bir metodoloji değil, bir çerçeve. Bunun anlamı Scrum, adım adım ne

yapmanız gerektiğini size söylemeyecek. İyi haber, ben, nasıl Scrum yaptığımı acı veren detaylı bir

şekilde anlatacağım. Kötü haber, bu sadece benim Scrum yapış şeklim, yani siz aynı şekilde

yapmalısınız diye bir şey yok. Hatta farklı bir durumda benim yapış şeklim de değişiklik gösterebilir.

Scrum’ın gücü ve zayıflığı, içinde bulunduğunuz belirli duruma göre onu adapte etmenizdir.

Benim Scrum’a olan yaklaşımım, bir yıldır 40 kişilik geliştirme takımıyla yaptığımız deneyin

sonucudur. Şirket zor durumdaydı, fazla mesai, ciddi kalite problemleri, sürekli yangın hali ve

kaçırılan teslim tarihleri vardı. Şirket Scrum uygulamaya karar verdi ve uygulamaya yardımcı olmam

için beni çağırdı. Geliştirme takımındaki birçok kişi için Scrum sözcüğü, günlük işlerinde hiç

kullanmadıkları, koridorda duydukları havalı bir ifadeydi.

16

Bir yıldan uzun bir süredir şirketteki bütün bölümlerde Scrum uyguluyoruz. Farklı büyüklüklerde(3-12

kişi) takımlar oluşturduk, farklı Sprint uzunlukları(2-6 hafta) denedik, Bitti Tanımı’nın farklı

uygulanışlarını, Ürün İş Listesi’nin ve Sprint İş Listesi’nin farklı formatlarını(Excel, Jira, indeks kart),

farklı test stratejilerini, demo yapmanın farklı yollarını, birden fazla Scrum Takımı’nı senkronize

etmenin farklı yollarını denedik. Ayrıca XP pratiklerini(Sürekli Entegrasyonun farklı yollarını, Eşli

Programlama ve Test Yönelimli Geliştirme) ve bu pratikleri Scrum’la nasıl birlikte yapabileceğimizi

deneyimledik.

Bu, süresiz öğrenme sürecidir yani hikaye burada bitmiyor. Eğer Sprint Retrospektifleri yapmaya

devam ederlerse, bu şirket öğrenmeye ve içinde bulundukları durumda Scrum’ı en iyi nasıl

uygulayabileceklerine dair yeni fikirler edinmeye devam edecek.

Açıklama

“Doğru şekilde” Scrum yapmayı anlatma iddiasında değilim! Sadece Scrum yapılış şekillerden birini

anlatacağım. Bir yıldan uzun bir sürede deneyimlediklerimi paylaşacağım. Belki yaptığımız her şey

sizin için yanlış bile olabilir.

Bu kitaptaki her şey benim kişisel görüşümü yansıtır. Bu kitaptakiler Crisp’in ya da müşterimin resmi

görüşleri değildir. Bu nedenle herhangi bir üründen ya da kişiden bahsetmeyeceğim.

Neden Yazdım?

Scrum’ı öğrenirken, Scrum ve Çeviklikle ilgili kitapları okudum, sitelerden ve forumlardan Scrum’la

ilgili bilgiler edindim, Ken Schwaber’den sertifika aldım, sorularımla onu kızdırdım ve iş

arkadaşlarımla fikir alışverişlerine çok zaman harcadım. En değerli bilgi kaynaklarından biri gerçek

savaş hikayeleriydi. Savaş hikayeleri, ilkeleri ve pratikleri, bu ilkelerin ve pratiklerin gerçek hayata

uyarlamasıdır, “gerçekte nasıl yapıldığıdır”. Savaş hikayeleri, aynı zamanda Scrum’a yeni

başlayanların yaptıkları hataları tanımlamamı sağladı ve bunları yapmamı engelledi.

Savaş hikayelerinden birçok şey öğrendim. İşte benim savaş hikayem, umarım siz de benim

hikayemden bir şeyler öğrenebilirsiniz.

17

Umarım benzer durumda olanlar işlerine yarayacak bilgileri bu kitapta bulurlar ve geribildirimde

bulunup bana bilgi verebilirler.

Ama Scrum Ne ki?

Scrum’ı ve XP’yi daha önce hiç duymadınız mı? Bu durumda aşağıdaki bağlantıları bakmalısınız.

● http://agilemanifesto.org/

● http://www.mountaingoatsoftware.com/scrum

● http://www.xprogramming.com/xpmag/whatisxp.htm

Eğer bunu yapamayacak kadar sabırsızsanız okumaya devam edebilirsiniz. Kitapta ilerledikçe Scrum

jargonunu açıklıyorum, bilginiz olmamasına rağmen çekici gelebilir.

Scrum Kılavuzu’na bakmayı unutmayın. Jeff Sutherland ve Ken Schwaber tarafından oluşturulan Scrum’ın resmi tanımıdır. http://www.scrumguiedes.org

18

Bölüm

İki

Ürün İş Listesi’ni nasıl oluştururuz?

Ürün İş Listesi, Scrum’ın kalbidir, her şeyin başladığı yerdir.

Ürün İş Listesi, temelde müşteri ihtiyaçlarının, kullanıcı hikayelerinin, işlevselliklerin(ya da siz adına

ne diyorsanız) önceliklendirilmiş bir listesidir. Müşterinin terminolojisi kullanılarak ifade edilmiş,

müşterinin istediği şeylerin listesi.

Biz, bunlara kullanıcı hikayeleri ya da sadece iş maddeleri diyoruz.

Bizim kullanıcı hikayelerinde aşağıdaki alanlar bulunuyor:

● No: Otomatik artan ve tekrar etmeyen bir numaradır. Eğer kullanıcı hikayelerine yeni ad

verirsek onları kaybetmeyiz, bu numaradan takip edebiliriz.

● Adı: Hikayeyi anlatan kısa, tanımlayıcı bir ifadedir. Örneğin, “işlem hareketlerinin tarihçesini

görme”. Geliştiriciler ve Ürün Sahibi’nin anlayabileceği, diğer kullanıcı hikayeleriyle

karıştırılmayacak kadar net olmalı. Ortalama 2-10 sözcük.

● Önem: Bu kullanıcı hikayesinin Ürün Sahibi için önemi derecesi. Örnek: 10, 150, Yüksek

ifadeleri çok önemli demek olabilir. 3, 50, Düşük ifadeleri o kadar da önemli değil demek

olabilir.

Hmm, hayır! Ürün İş Listesi, başlangıç noktası değildir. İyi bir ürün müşterinin ihtiyacıyla ve bu

ihtiyacın nasıl karşılanabileceğine öngören vizyonla başlar. Ürün İş Listesi, bu vizyonun, somut,

teslim edilebilir parçalara kadar detaylandırılmasının sonucudur. Vizyondan Ürün İş Listesi’ne

kadar olan yolculuk oldukça karmaşık olabilir. Aradaki boşluğu doldurmak için birçok teknik

kullanılabilir. Örneğin kullanıcı hikayesi haritası(Jeff Patton’ın kitabını okuyun, mükemmel), Yalın

UX, etki haritası oluşturma ve daha fazlası. Vizyon ve Ürün İş Listesi’ndeki boşluğu doldurmak için

en baştan çok büyük ve detaylı bir analizi bahane olarak kullanmayın. Ürün İş Listesi’nin zamanla

evrimleşmesine izin verin.

19

“Öncelik” ifadesini bilerek kullanmıyorum çünkü öncelik sıralamasında 1 en yüksek

öncelik demektir. Eğer bir işin önceliğini 1 olarak belirlerseniz ve sonra elinize daha

öncelikli bir iş gelirse önceliğini 0(sıfır) vermek zorunda kalırsınız!

● İlk Büyüklük: İşi gerçekleştirmek için takımın başlangıçta tahmin ettiği eforun büyüklüğü.

Birimi hikaye puanıdır ve kabaca ideal adam/gün’e denk gelir.

Takıma şunu sorun: Bir sürü yiyecekle odaya kilitlenmiş ve hiç rahatsız edilmemiş

olsalar, ideal sayıda kişiyle, bu işi kaç günde bitirebilirler. Eğer cevap üç kişiyle dört

günse o zaman ilk büyüklük 12 hikaye puanıdır.

Önemli olan nokta mutlak tahminler yapmak değildir, önemli olan nokta göreceli

tahminler yapmaktır.

● Demo: Sprint Değerlendirme Toplantısı’nda bu işin nasıl gösterilebileceğine dair kısa bir

açıklamadır. Temelde iş maddesinin nasıl çalışması gerektiğini anlatır ve testi buna göre

yaparız. “Butona tıkla, seçimi yap, şimdi A penceresi açılmalı”.

Eğer Test Yönelimli Geliştirme(TDD) ile uğraşıyorsanız, bu tanımlamayı kodunuzu

geliştirmek için kullanabilirsiniz.

● Açıklama: Herhangi bir bilgi, açıklama, referans vb.

Ürün İş Listesi(örnek)

No Adı Önem Büyüklük Demo Açıklama

1 Mevduat 30 5

Giriş yap, mevduat sayfasını aç, 10 TL yatır. Bakiye sayfasına git ve bakiyenin 10 TL artıp artmadığını kontrol et.

UML diyagramına ihtiyaç var. Şimdilik şifrelemeye ihtiyaç yok.

2

İşlem hareketlerinin tarihçesini görme

10 8

Giriş yap, mevduat hesabına para yatır. “İşlem hareketlerine” git, yeni yapılan işlemi kontrol et.

Veri tabanına çok gidip gelmemek için sayfalama yapısı kullan. Kullanıcılar sayfasındakine benzer bir tasarım yap.

Ürün İş Listesi’nde birçok alan kullanmayı denedik fakat günün sonunda elimizde sadece bu altı alan

kaldı. Sprint’ten Sprint’e fark ettik ki sadece bu alanları güncel tutuyoruz.

20

Ürün İş Listesi’ni bir excel dokümanı olarak saklarız ve ortak paylaşıma açarız. Böylece herkes aynı

anda girip bir şeyler ekleyebilir. Ürün Sahibi, bu dokümanın sahibidir fakat diğer kullanıcıların da bir

şeyler eklemesini isteriz. Geliştiriciler çoğu zaman bu dokümanı açar ve unuttukları bir şeyi

hatırlamaya çalışırlar ya da işin büyüklüğünü değiştirmek isterler vs.

Aynı sebepten dolayı bu dokümanı versiyon kontrol sistemine eklemeyiz. Paylaşımlı bir sürücüde

tutarız bu dokümanı böylece birçok kullanıcı aynı anda dokümanı kullanabilir.

Kullandığımız bütün diğer araçlar versiyon kontrol sisteminde tutulur.

Ürün İş Listesi’ndeki Diğer Alanlar

Ürün İş Listemizde başka alanlar da bulunur. Bu alanları, Ürün Sahibi’nin öncelikleri belirleme işini

kolaylaştırmak için kullanırız.

● Tip: Kullanıcı hikayesinin kategorisidir. Örneğin “arka ofis”, “teknik iyileştirme”. Böylece Ürün

Sahibi, bütün “teknik iyileştirme” işlerini fi ltreleyebilir ve önceliklerini düşürebilir, vb.

● Ortam: Genellikle excel dokümanındaki bir “onay kutucukları” olarak bulunur. Örneğin,

“veritabanı, server, client” gibi. Geliştirme Takımı ya da Ürün Sahibi, hangi ortamlarda

geliştirme yapılacağını görür. Birden fazla Scrum Takımı olduğunda kullanışlıdır. Arka ofis

takımı, müşteri takımı gibi takımlarınız olduğunda hangi takımın hangi işi alacağına karar

vermeyi kolaylaştırır.

Excel ha? Ne günlerdi ama! Şimdilerde Ürün İş Listesi’nin yönetimi için exceli hayatta düşünmem,

tabi bulut versiyonuysa değişebilir. Ürün İş Listesi, herkesin, her yerden erişebileceği, paylaşımlı

bir ortamda bulunması ve canlı tutulması gereken bir dokümandır. Zilyon tane iş listesi yönetim

aracı bulunur. Trello, LeanKit, Jira oldukça popülerdir. Google SpreadSheet oldukça pratiktir.

Şimdilerde farklı yaptığım iki şey var. Birincisi artık “önem” kolonu bulunmuyor. Önem kolonu

yerine sadece listeyi sıralıyorum. İş Listesi yönetim araçlarının hepsinde sürükle ve bırak özelliği

mevcut. Hatta Excel ve Google Spread Sheet bile bu özelliklere sahip, eğer yüksek derecede gizli

kısa yolları öğrenirseniz yapması çok hızlı ve çok kolay. İkinci olarak adam/gün asla

kullanmıyorum. İşlerin büyüklüğünü belirlerken hikaye puanlarından ya da tişört

büyüklüklerinden(küçük, orta, büyük) yararlanıyoruz. Hatta bazen işlerin büyüklüğünü hiç tahmin

etmiyoruz. Bu konuyu sonra anlatacağım.

21

● Talep eden: Ürün Sahibi, işin hangi paydaş ya da müşteri tarafından talep edildiğini tutmak

isteyebilir. Böylece işin ilerleyişi hakkında talep eden kişiye bilgi vermesi kolaylaşır.

● Hata takip numarası: Eğer hataları takip ettiğiniz ayrı bir sisteminiz varsa (bizim Jira da takip

ettiğimiz gibi) kullanıcı hikayesinde bu hatanın numarasını tutmak faydalıdır. Hataya erişmek

istediğinizde bu numarayla kolayca erişebilirsiniz.

Ürün İş Listesi’ni İş Birimine(Müşteriye) Anlamlı Gelecek Seviyede

Tutma

Eğer Ürün Sahibi teknik bilgiye sahipse; “işlem tablosuna index eklenmeli” gibi kullanıcı hikayeleri

oluşturabilir. Bunu neden isteyebilir? Arama sayfasını hızlandırmak istediği için.

İndex’lerin olmaması yavaşlığın nedeni olmayabilir. Bambaşka bir şey arama sayfasındaki yavaşlığın

nedeni olabilir. Normal şartlar altında Geliştirme Takımı bir şeyin nasıl çözüleceğini daha iyi bilir. Yani

Ürün Sahibi gerçekleştirilecek işin hedeflerine odaklanmalıdır.

Böyle teknik yazılmış kullanıcı hikayeleri gördüğüm zaman Ürün Sahibi’ne bir dizi “ama neden?”

sorusu sorarım taa ki iş açısından hedefi bulana kadar. Daha sonra bu hedefin olduğu yeni bir

cümleyle kullanıcı hikayesini baştan oluştururuz. Bu örnekte “arama sayfasının hızlandırılması”

şeklinde düzenledik. İlk oluşturulan kullanıcı hikayesi “işlem tablosuna index eklenmeli” açıklama

kolonuna yazılabilir.

Bunun için eski ve iyi bir yöntem var. “A rolündeki kullanıcı olarak B işlevselliğinin geliştirilmesini

istiyorum böylece C işlemi gerçekleştirebileceğim”. Alıcı rolündeki kullanıcı olarak sipariş listemi

kaydetmek istiyorum böylece yarın alışveriş yapmaya devam edebileceğim. 2007 yılında bunu

duymadığıma inanamıyorum! Bugün daha ayrıntılı birçok şablon var. Fakat bu şablon çok basit ve

Çeviklik konusunda yeni olanlar için iyi bir başlangıç noktası olabilir. Şablon sizi doğru sorular

sormaya zorluyor ve teknik detaylarda kaybolmanızı engelliyor.

22

Bölüm

Üç

Sprint Planlama’ya Nasıl Hazırlanıyoruz?

Sprint Planlama günü çok çabuk gelir. Tekrar tekrar öğrendiğimiz ders: Ürün İş Listesi’nin Sprint

Planlama Toplantısı’ndan önce düzgün bir hale getirilmesidir.

Ürün İş Listesi’nin doğru düzgün bir hale getirilmesi ne anlama gelir? Ürün İş Listesi’ndeki tüm

maddeler mükemmel bir şekilde mi anlatılmalıdır? İş büyüklükleri mükemmel doğrulukta mı

verilmelidir? Önceliklerin belirlenmiş olması mıdır? Hayır, hayır! Anlatmak istediğim şey:

● Ürün İş Listesi var olmalıdır.(Hayal edin, olmayan Scrum Takımları var!)

● Bir Ürün İş Listesi ve bir Ürün Sahibi olmalıdır.

● Ürün İş Listesi’ndeki bütün işlerin öncelikleri belirtilmelidir, her iş maddesi farklı önceliklere

sahip olmalıdır.

○ Önceliği çok düşük olan ve Sprint Planlama’da konuşulmayacak olan maddelerin

öncelikleri verilmeyebilir ya da aynı önceliklere sahip olabilirler.

○ Uzak bir ihtimalle de olsa bir sonraki Sprint’te gerçekleştirilebilecek işlerin farklı

öncelikleri olmalıdır.

○ Öncelik oranı sadece işleri önceliklerine göre sıralamak için kullanılır. Yani A

maddesinin öncelik oranı 20, B maddesinin öncelik oranı 100 ise B, A’dan daha

önemli bir iş demektir. B’nin A’dan 5 kez daha önemli olduğu anlamına gelmez. Eğer

B’nin öncelik oranı 21 ise hala A’dan daha önemli bir madde olduğu anlaşılır.

○ İş maddelerinin önceliklerini belirlediğimiz sayılar arasında farklar olması iyidir.

Örneğin C maddesi A ve B’nin arasında bir yerde olması gerekirse 20-21 arasına 20.5

Ürün İş Listesi doğru düzgün oluşturulmadığı için patlayan birçok Sprint Planlama Toplantısına

şahit oldum. “Shit in = shit out” deyimini bilirsiniz, değil mi?

23

öncelik oranını kullanabilirsiniz fakat güzel olmaz. Yani öncelik oranları arasında yeni

eklenecek maddeler için boşluk bırakın.

● Ürün Sahibi her bir kullanıcı hikayesini anlamalıdır. Normalde kullanıcı hikayelerini Ürün

Sahibi yazar fakat bazı durumlarda diğer kişilerde Ürün İş Listesi’ne eklemelerde bulunabilir.

Eklenen bu maddeleri sadece Ürün Sahibi önceliklendirebilir. Teknik olarak ne yapılması

gerektiğini anlamasına gerek yoktur fakat neden eklenmesi gerektiğini bilmelidir.

Not: Ürün Sahibi dışında diğer kişiler de Ürün İş Listesi’ne kullanıcı hikayeleri ekleyebilir fakat

önceliğini belirleyemezler. Aynı şekilde işin büyüklük tahminini de yapamazlar. İşin büyüklük

tahminini sadece takım yapabilir. İşlerin önceliğini belirlemek Ürün Sahibi’nin, işlerin büyüklüğünü

belirlemek Geliştirme Takımı’nın sorumluluğu ve hakkıdır.

Denediğimiz ve değerlendirdiğimiz diğer yaklaşımlar:

● Ürün İş Listesi’ni tutmak için Jira’yı kullandık. Birçok Ürün Sahibi bunu sıkıcı buldu. Excel daha

güzel ve değiştirmesi çok daha kolay geldi. Satırları anında boyayabiliyor, öncelikleri anında

değiştirebiliyorsunuz, yeni kolonlar ekleyebiliyorsunuz. Notlar ekleyebiliyor, import ve export

yapabiliyorsunuz.

VersionOne, ScrumWorks, XPlanner gibi Çevik süreçleri destekleyen araçları kullanma şansımız

olmadı. Gelecekte belki kullanabiliriz.

Aynı şekilde Google Spreadsheets’te bu özelliklere sahip. Ayrıca bir bulut çözümü, birden fazla

kullanıcı aynı anda değişiklik yapabiliyor. Sadece söylüyorum...

Sadece Ürün İş Listesi’ni sıralayın. Öncelik oranıyla vaktinizi boşa harcamayın.

24

Bölüm

Dört

Sprint Planlama’yı Nasıl Yapıyoruz?

Sprint Planlama önemli bir toplantıdır. Kişisel fikrime göre Scrum’daki en önemli toplantıdır. Kötü

yapılan bir Sprint Planlama Toplantısı bütün Sprint’in kötü geçmesine neden olabilir.

Sprint Planlama Toplantısı’nın amacı, Geliştirme Takımına, birkaç hafta bölünmeden çalışabileceği

kadar bilgi sağlamak ve Ürün Sahibi’ne işlerin bitirilmesi için güven vermektir.

Tamam, bu biraz kafa karıştırıcı, Sprint Planlama Toplantısı’nın daha somut çıktıları:

● Sprint Hedefi

● Takım üyelerinin listesi(işi yapma tamamlama taahhütleri(commitment))

● Sprint İş Listesi(Sprint’e alınan işlerin listesi)

● Tarihi belirlenmiş değerlendirme toplantısı

● Günlük toplantının yapılacağı yer ve zaman

Önemli mi? Evet. Scrum’daki en önemli toplantı mı? Hayır! Retrospektif toplantıları çoook daha

önemlidir! Çünkü iyi yapılan retrospektif toplantıları yanlış yapılan ya da çalışmayan diğer şeylerin

düzeltilmesini sağlayabilir. Her şey(iyi bir Ürün İş Listesi, birbirini anlayan bir Ürün Sahibi ve

Geliştirme Takımı) iyi işliyorsa Sprint Planlama Toplantıları’nın o kadar da önemi kalmıyor. Ayrıca

Sprint’ler koşmak Çevik olmak için tek yol değildir. Birçok takım Kanban kullanıyor. Hatta bu

konuda küçük bir kitap bile yazdım: Kanban ve Scrum, İkisinin de En İyisini Yapmak

(http://www.yilmazcihan.com/kanban-ve-scrum-ikisinin-de-en-iyisini-yapmak/)

25

Ürün Sahibi Neden Katılmak Zorunda?

Bazı Ürün Sahipleri, Sprint Planlaması yapılırken Geliştirme Takımı’yla birlikte zaman harcamaya karşı

direnç gösterirler. “İstediklerimi sıraladım. Sizin planlamanıza ayıracak vaktim yok.” Bu oldukça ciddi

bir problemdir.

Geliştirme Takımı’nın ve Ürün Sahibi’nin Sprint Planlama Toplantı’sında bir arada olmasının nedeni

her kullanıcı hikayesinin içerdiği ve birbirine oldukça bağımlı olan üç değişkendir.

Kapsam ve öncelik, Ürün Sahibi tarafından belirlenir. İşlerin büyüklüğü Geliştirme Takımı tarafından

belirlenir. Sprint Planlama Toplantısı boyunca bu üç değişkene yüz yüze iletişim aracılığıyla ince ayar

çekilir. Normal şartlar altında Ürün Sahibi, Sprint hedefini ve en önemli kullanıcı hikayelerini

özetleyerek toplantıya başlar. Sonra Geliştirme Takımı her bir kullanıcı hikayesinin üzerinden geçer

ve işlerin büyüklüğünü tahmin eder. Geliştirme Takımı bunu yaparken kapsamla ilgili önemli sorular

sorabilirler.

- Bu “kullanıcı sil” maddesi, kullanıcının bekleyen işlerini iptal etmeyi içerir mi ?

Bazı durumlarda cevaplar Geliştirme Takımını şaşırtır, ilk verdikleri işin büyüklüğü tahminlerini

değiştirmek isteyebilirler.

Bazı durumlarda kullanıcı hikayesinin tahmini Ürün Sahibi’nin beklemediği bir tahmin olabilir. Bu da

Ürün Sahibi’nin o işle ilgili düşüncesini değiştirebilir ve işin önceliğini düşürebilir. Kullanıcı hikayesinin

kapsamını daraltabilir. Eğer kapsamı daraltırsa Geliştirme Takımı yeniden işin büyüklüğünü tahmin

eder.

Bu tip yüz yüze iletişim Scrum’ın temelidir, aslında tüm Çevik yazılım geliştirmenin temelidir.

26

Peki ya Ürün Sahibi yine de zamanı olmadığı konusunda ısrar ederse? Genellikle aşağıdaki stratejileri

izlerim:

● Ürün Sahibi’nin toplantıya katılımının neden bu kadar önemli olduğunu anlatmaya çalışır ve

fikrini değiştirmesini umarım.

● Geliştirme Takımı’ndan birinin vekil Ürün Sahibi gibi davranmasını isterim. Gerçek Ürün

Sahibine şunu söylerim: Madem ki bizim toplantımıza katılmak için vaktin yok o zaman

toplantıda Jeff seni temsil edecek. Önceliklerin belirlenmesinde, kapsamın değiştirilmesinde

tam yetkiye sahip olacaktır. Sana tavsiyem mümkün olduğunca Jeff’le beraber çalış ve bilgini

senkronize et. Eğer Jeff’in vekil olması hoşuna gitmiyorsa o zaman yerine birini öner.

● Üst yönetimi yeni bir Ürün Sahibi ataması için ikna etmeye çalışırım.

● Ürün Sahibi katılmak için zaman bulana kadar Sprint’in başlamasını ertelerim. Bu zaman

içinde herhangi bir isteğin teslim edilmesini reddederim. Geliştirme Takımı için en önemli

işler hangileriyse onların yapılmasını sağlarım.

Kalitenin Neden Pazarlığı Olmaz?

Yukarıdaki üçgende dördüncü değişkeni bilerek görmezden geldim: kalite.

Kaliteyi ikiye ayıracağım, iç kalite, dış kalite.

● Dış Kalite sistemin son kullanıcıları tarafından algılanır. Yavaş ve kullanıcı ihtiyaçlarını

karşılamayan bir kullanıcı ara yüzü kötü dış kalitenin örneğidir.

● İç Kalite, son kullanıcının görmediği fakat sistemin bakımını kapsayan tüm konulardır. Sistem

tasarım tutarlılığı, otomatik test sistemi, kod okunurluğu vb.

Yüksek iç kaliteye sahip bir sistem düşük dış kaliteye sahip olabilir. Fakat iç kalitesi düşük bir sistem

çok nadir olarak yüksek dış kaliteye sahip olabilir. Çürük bir temelin üzerine güzel bir şey inşa etmek

zordur.

Bu bölümde iyi şeyler yazmışım!<sırtımı sıvazlıyorum>

Tek bir şey, işlerin detaylandırılması(işlerin büyüklüğünün verilmesi, büyük kullanıcı hikayelerinin

küçük kullanıcı hikayelerine bölünmesi) için ayrı bir toplantı yapın. Böylece Sprint Planlama

Toplantısı daha odaklanmış bir şekilde geçecektir. Her iki toplantıda Ürün Sahibi’nin katılımı çok

önemlidir.

27

Dış kaliteyi kapsamın bir parçası olarak görürüm. Bazı durumlarda yavaş bir ekrana sahip sistemi

teslim etmek oldukça mantıklı olabilir. İşleri düzene oturttuktan sonra ekranı hızlandıracak çalışma

yapılarak yeni bir sürüm çıkılabilir. Buradaki pazarlığı Ürün Sahibine bırakırım çünkü kapsamdan o

sorumludur.

Oysa iç kalitenin tartışması olmaz. Sistemin kalitesinin korunması takımın sorumluluğundadır ve bu

en basit haliyle pazarlığa açık değildir.

Peki, iç kalite ve dış kalite arasındaki farkı nasıl ayırabiliriz?

Diyelim ki Ürün Sahibi şöyle bir şey söylüyor: “6 hikaye puanı tahmininize saygı duyuyorum fakat

eminim kendinizi işe verirseniz daha az zamanda hızlıca bir çözüm bulabilirsiniz.”

Tam işte burada dikkat! İç kaliteyi bir değişken olarak kullanmaya çalışıyor. Nerden biliyorum? Çünkü

kapsamı daraltmadan işin daha az zamanda yapılmasını istiyor. “Hızlıca bir çözüm” ifadesi kafanızda

alarmlar çaldırmalıdır.

İç kalitenin pazarlık konusu olmasına neden izin vermiyoruz?

Deneyimlerime göre iç kaliteden ödün vermek her zaman çok çok kötü bir fikirdir. İşi kalitesiz

yaparak kazanılan zaman hem kısa hem uzun dönemdeki maliyetin yanında çok küçük bir kazanımdır.

Kod bir kere kötüleşmeye başladığı zaman sonradan kaliteyi yeniden yükseltmek oldukça zordur.

Bunun yerine tartışmayı kapsama doğru yönlendiririm. “Bu işlevselliği erkenden elde etme k senin

için önemli olduğuna göre kapsamı daraltabilir miyiz? Böylece entegre etmemiz daha kolay olacaktır.

Belki hataları göstermeyi basitleştirebiliriz ve ileride bununla ilgili bir kullanıcı hikayesi ekleriz. Diğer

kullanıcı hikayelerinin önceliklerini de düşürebilirsin. Böylece sadece istediğin bu işlevselliğe

odaklanabiliriz, ne dersin?”

Bir Ürün Sahibi, iç kalitenin pazarlık konusu olmadığını öğrendiği zaman diğer değişkenleri manipule

etmeyi oldukça iyi öğrenir.

28

Bitmeyen Sprint Planlama Toplantıları!

Sprint Planlama Toplantılarının en zor yönü: İnsanlar çok uzun süreceğini düşünmezler fakat bu

toplantılar gerçekten çok uzun sürebilir!

Scrum’daki her etkinliğin süresi belirlidir. Bu basit ve tutarlı bir kuraldır. Bu kurala uymaya çalışırız.

Sprint Planlama Toplantısı’nın sonuna yaklaştığımız halde Sprint Hedefi ya da Sprint İş Listesi hala

oluşturulamamış olursa ne yapmalıyız? Sprint Hedefini ve Sprint İş Listesi’ni belirlemeden kısa kesip

toplantıyı bitirmeli miyiz? Yoksa bir saat daha uzatmalı mıyız? Ya da toplantıyı bitirip yarın sabah

devam mı etmeliyiz?

Bu, yeni takımların tekrar tekrar yaşadığı bir durumdur. Eee, ne yaparsınız? Bilmiyorum, ne

yapmalıyız? Ben genelde zalim bir şekilde toplantının süresi dolduğunda toplantıyı bitiri rim. Sprint

içinde takımın acı çekmesini isterim ki neyi yanlış yaptıklarını anlasınlar. Aslında Geliştirme Takımı’na

ve Ürün Sahibi’ne söylediğim tam olarak şöyle bir şey: “Bu toplantı 10 dakika sonra bitiyor. Sprint

Planı yok gibi bir şey. Elimizde olanla Sprint’e başlayalım yoksa yarın sabah 8’de dört saatlik başka bir

planlama toplantısı ayarlayalım mı?” Ne cevap verdiklerini tahmin edebilirsiniz. :)

Toplantının sürmesine izin verdiğim zamanlar da oldu. Toplantının devam etmesi çokta başarılı bir

yaklaşım olmadı. Çünkü insanlar yorulmuş oluyorlar. Eğer belirlenen dört saatlik zamanda doğru

Teoride evet. Fakat bugünlerde pratikte daha faydacı olmaya eğilimliyim. Bazen iş açısından

kaliteden vazgeçmek oldukça mantıklı olabilir. Örneğin gelecek Sprint’ten sonra oldukça önemli

bir fuar var ya da kullanıcı davranışlarını görebilmemiz için sadece bir prototipe ihtiyacımız var.

Böyle durumlarda kaliteden neden ödün verdiğimizi Ürün Sahibi çok net bi r şekilde açıklamalıdır.

İlerleyen zamanlardaysa bu teknik borcun ödenmesi için Geliştirme Takımı’na yeterli zamanı

vermelidir. Böyle işler için takımlar Ürün İş Listesi’ne temizlik adında bir iş maddesi eklerler,

böylece gelecekte bu işi unutmamış olurlar. Yüksek iç kalite bir kural olmalı ve yapılan istisnalar

kaideyi bozmamalıdır.

Hayır, o kadarda çok zaman harcamak zorunda değilsiniz! Eğer gelecek Sprint’e alınacak işleri

içinde bulunduğunuz Sprint içinde yaptığınız aktivitelerle detaylandırırsanız o kadar uzun

sürmeyecektir. Ürün İş Listesini detaylandırmak için haftada bir, bir saatliğine toplanan birçok

takım gördüm. Böylece Sprint Planlama Toplantısı daha odaklanılabilir bir toplantı olur. Ayrıca bu

Ürün Sahibine verilmiş bir şans olarak ortaya çıkar. Rehber: Sprint Planlama Toplantısı bir haftalık

Sprint’lerde bir saatten fazla sürmemelidir. Deneyimli takımlarda daha da az sürmesi beklenir.

Yani üç haftalık Sprint’ler koşan takımlarda üç saatle sınırlı olmalıdır.

29

düzgün bir Sprint Planı oluşturamadılarsa toplantı birkaç saat uzasa dahi oluşturamayacaklardır.

Aslında ikinci seçenek de oldukça mantıklıdır, ertesi sabah yeni bir toplantı yapmak. İnsanların

sabırsız olması ve Sprint’e başlamak istemeleri dışında yeni bir planlama yapmanın sakıncası yoktur.

Yani Sprint Planlama Toplantısı’nın zamanı dolduğunda toplantının bitirilmesini, Sprint içinde

Geliştirme Takımı’nın ve Ürün Sahibi’nin acı çekmesini sağlarım. Bunun iyi yanı Geliştirme Takımı’nın

ve Ürün Sahibi’nin oldukça değerli bir ders almış olmasıdır. Gelecek Sprint Planlama Toplantısı çok

daha verimli olacaktır. Ayrıca insanlar daha önce uzun olduğunu düşündükleri bir topl antı

ayarladığınızda daha az direnç göstereceklerdir.

Süresi belirli etkinlikleri zamanında bitirmeyi öğrenin, etkinliklerin süresini belirlerken gerçekçi olun.

Bunu hem toplantılarınızın uzunluklarını hem de Sprint uzunluğunuzu belirlerken uygulayın.

Sprint Planlama Toplantısı’nın Yapısı

Sprint Planlama Toplantısı’nın nasıl gerçekleştirileceği önceden belirlenirse toplantı süresinin aşılma

riski azalmış olur.

Aşağıda Sprint Planlama Toplantısı için basit bir yapı bulunuyor:

Sprint Planlama Toplantısı: 13:00-17:00 Her saat başında 10 dakika ara.

● 13:00 - 13:30 - Ürün Sahibi, Sprint Hedefi’nden bahseder ve Ürün İş Listesi’ni özetler.

Demonun yapılacağı yer, tarih ve saat belirlenir.

● 13:30 - 15:00 - Takım işlerin büyüklüğünü belirler ve işler büyükse daha küçük parçalara

böler. Eğer gerekliyse Ürün Sahibi işlerin önceliklerini günceller. Sprint’e alınacak maddeler

netleştirilir. Demonun nasıl yapılacağı yüksek öncelikli bütün maddeler için belirlenir.

“Scrum’ı denedik, nefret ettik, bir daha yapmayacağız!” diyen bir takımla karşılaştım. Neden diye

sorduğumda “herhangi bir şey bitiremiyoruz, toplantılarda çok fazla zaman harcıyoruz” cevabını

verdiler. En çok hangi toplantıya zaman harcadıklarını sordum. Sprint Planlama Toplantısı

olduğunu söylediler. Sprint Planlama Toplantısı’nın ne kadar sürdüğünü sordum ve “iki ya da üç

gün” diye cevap verdiler. Her Sprint için iki ya da üç gün planlama mı?! Neden nefret ettikleri

belli! Süresi belirli etkinlikler kuralını gözden kaçırmışlar. Planlamaya ne kadar yatırım yapmanız

gerektiğine en baştan karar vermelisiniz ve buna sadık kalmalısınız! Scrum’da tıpkı diğer araçlar

gibidir, çekici bir çivi çakmak içinde kullanabilirsiniz, parmağınızı ezmek içinde. Ne olursa olsun,

aracı suçlayamazsınız!

30

● 15:00 - 16:00 - Geliştirme Takımı, Sprint’e alınacak işleri seçer. Takım hızını hesaplayarak

kapasiteyi belirler.

● 16:00 - 17:00 - Bir önceki Sprint’ten farklı olacak Günlük Scrum Toplantıları için yer ve zaman

belirlenir. Kullanıcı hikayeleri işlere(task’lara) bölünür.

Bu zamanla katı bir şekilde dayatılmamalıdır. Scrum Master, bölümler arasındaki süreyi kısaltabilir ya

da uzatabilir, buna toplantının ilerleyişine göre karar verilmelidir.

Sprint Uzunluğunu Belirleme

Sprint Planlama Toplantısı’nın çıktılarından biri demonun yapılacağı tarihtir. Bunun anlamı da Sprint

uzunluklarını belirlemektir.

Peki, iyi bir Sprint uzunluğu ne kadar olmalıdır?

Kısa Sprint’ler iyidir, kurumun çevik olmasını sağlar, kısa Sprint’lerde yönünüzü daha çabuk

değiştirebilirsiniz.

Kısa Sprint’ler = Kısa Geribildirim Döngüleri = Daha Sık Teslimler = Müşteriden Daha Çok Geribildirim

= Yanlış Yönde İlerlemeye Harcanan Zaman Azalır = Daha Hızlı Öğrenilir ve Gelişim Gösterilir

Fakat uzun Sprint’ler de iyidir. Takım odaklanacağı daha fazla zamana sahip olur, problemlerin

çözümü için daha fazla zaman vardır. Böylece Sprint Hedefine erişebilirler. Sprint Planlama Toplantısı

ve demonun nerede, nasıl yapılacağı gibi konularda daha az yük olur.

Genel olarak Ürün Sahipleri kısa Sprint’lerden, Geliştirme Takımları uzun Sprint’lerden hoşlanır. Yani

Sprint’in uzunluğu anlaşmaya varılması gereken bir konudur. Bu konuda çok deney yaptık ve bizim

için en iyi uzunluğu belirledik, üç hafta. Takımlarımızın çoğu üç haftalık Sprint’ler koşar. Üç haftalık

süre kurum için yeterli derecede Çeviklik sağlar ve Geliştirme Takımı için geliştirmeye

odaklanabilecekleri süreye sahip olunur.

13:30 ve 15:00 arasındaki bölüm, Ürün İş Listesi detaylandırma bölümüdür. Bu bölümü ayrı bir

toplantı olarak yapabilirsiniz. Böylece daha kısa ve daha verimli planlama toplantıları

yapabilirsiniz. Detaylandırma toplantısından sonra gelen işler için küçük birkaç ayarlama

gerekebilir, sonradan gelen bu maddeleri Sprint Planlama Toplantı’sında detaylandırmanız

gerekebilir ama olsun, yinede oldukça verimli bir toplantı yapabilirsiniz.

31

Sonunda öğrendiğimiz bir şey başlangıçta Sprint uzunluğuyla ilgili bolca deney yapılması gerektiğidir.

Sprint uzunluğunu belirlemek için fazla detaylı analiz yapmayın, düzgün bir uzunluk seçin ve birkaç

Sprint deneyin daha sonra yeniden Sprint uzunluğunu değiştirin ve deneyin.

Bazen biraz uzun gibi hissettirecek, bazen biraz kısa gibi. Fakat Sprint uzunluğunuzu belirledikten

sonra bu zamanla kurumun kalp atışına dönüşecektir. Teslim tarihleri konusunda herhangi bir

tartışma yaşanmayacak çünkü her üç haftada bir teslim yapılacağı herkes tarafından bilinecek.

Sprint Hedefi’ni Belirleme

Sprint Planlama Toplantısı’nın herhangi bir anında, “bu Sprint’in hedefi nedir” diye sorarım. Herkes

boş gözlerle bana bakar, Ürün Sahibi kaşlarını çatar ve çenesini kaşır. Bu neredeyse çalıştığım bütün

takımlarda böyledir.

Bir nedenden ötürü Sprint Hedefi’ni belirlemek zordur. Şunu öğrendim, hiç olmayan bir hedeftense

yarım yırtık bir hedef iyidir. Hedef, “daha fazla para kazanmak”, “önceliği en yüksek üç işi bitirmek”,

“Genel Müdürü etkilemek”, “beta versiyonu çıkabilecek kadar sistemi iyileştirmek”, “arka ofis destek

işlevselliğini eklemek” olabilir. Önemli olan şey iş birimi, müşteri terimlerini kullanarak belirlemektir,

teknik terimleri kullanarak değil. Böylece takım dışındaki kişiler de Sprint Hedefi’ni anlayabilir.

Sprint Hedefi oldukça basit ve temel bir soruya cevap verebilmelidir: “Bu Sprint’i neden yapıyoruz?

Neden hepimiz tatile gitmiyoruz?” Sprint Hedefi’ni belirlemenin bir yolu da Ürün Sahibi’ne bu soruyu

sormaktır.

Sprint Hedefi, hali hazırda ulaşılmamış bir hedef olmalıdır. “Genel Müdürü etkilemek” iyi bir hedef

olabilir fakat bu hedef koyulana kadar etkilenmemiş olması gerekir. Böyle bir durumda herkes eve

gidebilir çünkü Sprint Hedefi’ne hali hazırda erişilmiştir.

Çalıştığım tüm Scrum Takımları eninde sonunda iki ya da üç haftalık Sprint’ler koşmaya karar

verirler. Bir hafta oldukça kısadır. Sprint’e daha yeni başladık ve şimdi demonun nasıl yapılacağını

konuşuyoruz. Bu oldukça stres yaşatır. Hızlanmamıza ve geliştirme işinden zevk almamıza yeterli

zaman yok! Dört haftaysa oldukça uzundur. Planlama toplantılarımız işkenceye dönüşüyor ve

Sprint’in içinde sürekli olarak bölünüyoruz.

Bunlar sadece benim gözlemlerim.

32

Sprint Hedefi, Sprint Planlama süresince saçma ve yapmacık görünebilir, Sprint ortasındaysa daha

kullanışlı görünmeye başlayacaktır. Geliştirme Takımı’ndaki kişilerin Sprint ortasında ne yapmaları

gerektiği konusunda kafaları karışmaya başladığı zaman Sprint Hedefi’ne odaklanabilirler. Eğer bizim

gibi birden fazla üründe çalışan birden fazla Scrum Takımınız varsa bu takımların Sprint Hedeflerini

bir wiki sayfasında göstermek oldukça kullanışlı olabilir. Sprint Hedeflerini böyle önemli bir şekle

sokmak ve yalnızca üst yönetimin değil herkesin kurumun ne yaptığını ve neden yaptığını görmesini

sağlar.

Sprint’e Hangi İşlerin Alınacağını Belirleme

Sprint Planlama Toplantısı’nın başlıca etkinliklerinden biri hangi kullanıcı hikayelerinin Sprint’e

alınacağına karar vermektir. Özetle Ürün İş Listesi’ndeki hangi iş maddeleri Sprint İş Listesi’ne

kopyalanacak buna karar vermektir.

Yukarıdaki resme bakın. Her dikdörtgen öncelik sırasına göre dizilmiş olan bir kullanıcı hikayesini

temsil etmektedir. En önemli kullanıcı hikayesi Ürün İş Listesi’nin en üstünde bulunur.

Dikdörtgenlerin büyüklüğü ilgili kullanıcı hikayesinin büyüklüğünü gösterir. Küme parantezinin

yüksekliği göreceli takım hızını gösterir. Yani takım gelecek Sprint’te bitirebileceğini düşündüğü

işlerin toplam büyüklüğüdür.

Sağdaki Sprint İş Listesi, Ürün İş Listesi’ndeki kullanıcı hikayelerinin bir kopyasıdır. Geliştirme

Takımı’nın gelecek Sprint’te bitirmeyi taahhüt ettiği kullanıcı hikayelerinin listesidir.

Scrum Kılavuzu bile her Sprint’in bir hedefinin olması gerektiğini söyler. Fakat bence Sprint

bazında bir hedefin olması çok elzem değil. Birkaç Sprint’i ya da gelecek teslimi kapsayan üst

seviye bir hedef de iyi olur. Sadece Sprint’in birkaç kullanıcı hikayesinin bitirilmesinden daha

önemli bir şey olduğundan emin olun. Scrum Takımı bir hedefe doğru ilerlemelidir yoksa birkaç

Sprint’ten sonra herkesin sıkılmaya başladığını görebilirsiniz.

33

Sprint’e ne kadar iş alınacağına takım karar verir, Ürün Sahibi ya da bir başkası değil!

Bu, iki soruyu akıllara getirir:

1. Hangi işlerin Sprint’e alınacağına takım nasıl karar verir?

2. Ürün Sahibi, takımın kararlarını nasıl etkileyebilir?

İkinci soruyla başlayacağım.

Sprint’e Hangi İşlerin Alınacağı Konusunda Ürün Sahibi’nin Etkisi

Nedir?

Diyelim ki Sprint Planlama Toplantısı’nda aşağıdaki gibi bir durum yaşıyoruz.

D kullanıcı hikayesi Sprint’e alınamayacağı için Ürün Sahibi hayal kırıklığına uğramış durumda.

Seçeneklerden biri yeniden önceliklendirmedir. Eğer D maddesinin önceliğini en yüksek seviyeye

çıkarırsa Geliştirme Takımı D maddesini Sprint’e almakla yükümlüdür. Tabi bu durumda C maddesi

Sprint’e dahil edilmeyecektir.

İkinci seçenek kapsamı değiştirmektir. A kullanıcı hikayesinin kapsamı daraltılarak takımın D

maddesini de Sprint’ine dahil etmesi sağlanabilir.

34

Üçüncü seçenek A kullanıcı hikayesini daha küçük parçalara bölmek olabilir. Ürün Sahibi, A kullanıcı

hikayesinin bazı özelliklerinin o kadar da önemli olmadığına karar verebilir. Daha sonra A kullanıcı

hikayesini A1 ve A2 şeklinde iki kullanıcı hikayesine böler.

Gördüğünüz gibi Ürün Sahibi takım hızını ya da Sprint’e ne kadar iş alınacağını kontrol edemese bile

hangi kullanıcı hikayelerinin Sprint’e alınacağını yukarıdaki örneklerde olduğu gibi belirleyebilir.

Sprint’e Hangi İşlerin Alınacağına Geliştirme Takımı Nasıl Karar

Verir?

Bunun için iki teknik kullanırız:

1. Geliştirme Takımı içgüdüsel karar verir.

2. Geliştirme Takımı’nın hızını hesaplarız.

İçgüdüsel Karar Verme

Scrum Master: (Ürün İş Listesi’ndeki en önemli maddeyi göstererek) A kullanıcı hikayesini bu

Sprint’te bitirebilir miyiz?

Lisa: Elbette bitirebiliriz. Üç haftamız var ve bu oldukça küçük bir kullanıcı hikayesi.

Scrum Master: (Ürün İş Listesi’ndeki ikinci en önemli maddeyi gösterir) Tamamdır. Peki, B kullanıcı

hikayesini Sprint İş Listesi’ne ekleyebilir miyiz?

Tom ve Lisa: (Beraber) İkisini beraber geliştirmek bizi çok zorlamaz, yapabiliriz.

Scrum Master: Peki A,B,C kullanıcı hikayelerini beraber alabilir miyiz?

35

Sam:(Ürün Sahibine dönerek) C kullanıcı hikayesi kullanıcının karşılaştığı hatalara uyarı verilmesini

içeriyor mu?

Ürün Sahibi: Hayır, şimdilik bu konuyu atlayabilirsiniz. Sadece temel hatalar çözülmeli.

Sam: O zaman C kullanıcı hikayesini de alabiliriz.

Scrum Master: Peki, D kullanıcı hikayesini alabilir miyiz?

Lisa: Hmmm….

Tom: Bence alıp bitirebiliriz.

Scrum Master: Bitirebileceğimizde %90 mı %50 mi eminsin?

Tom ve Lisa: %90.

Scrum Master: O zaman D’yi de Sprint’e aldık. E kullanıcı hikayesini alabilir miyiz?

Sam: Belki.

Scrum Master: %90, %50?

Sam: Bence %50.

Lisa: Şüpheliyim.

Scrum Master: Peki o zaman E’yi almıyoruz. A,B,C ve D’yi bitireceğimize dair taahhüt veriyoruz. Eğer

bütün bunları bitirebilirsek E’yi de alabiliriz ama şimdilik almıyoruz.

Herkes: Tamamdır!

Geliştirme Takımı’nın Hızını Hesaplama

Bu teknik iki adımdan oluşur:

1. Takımın göreceli hızına karar ver.

2. Takımın hızını aşmadan kaç kullanıcı hikayesinin Sprint’e alınabileceğine karar ver.

Takım hızı, Geliştirme Takımı’nın bir Sprint’te bitirdiği işlerin toplamıdır.

Aşağıdaki resim Sprint başındaki göreceli tahmin edilen takım hızını ve Sprint sonundaki gerçek takım

hızını göstermektedir. Her bir dikdörtgen bir kullanıcı hikayesidir ve içerisindeki sayı Sprint başında o

kullanıcı hikayesi için belirlenen büyüklük tahminidir.

36

Gerçek takım hızı, başlangıçtaki tahminlere göre hesaplanır. Sprint içinde bir kullanıcı hikayesinin

büyüklüğü değiştirilemez.

Şimdiden itiraz ettiğinizi duyar gibiyim: “Bunun ne faydası var ki? Yüksek ya da düşük takım hızı

birçok etkene bağlı olarak değişebilir. Beyinsiz yazılım geliştiriciler, doğru olmayan ilk tahminler,

kapsamın artması, Sprint içinde gelen acil işler!”

İnce bir hesap yapılmadan belirlenen kabaca hesaplanan bir sayı olduğuna katılıyorum. Fakat oldukça

kullanışlı bir sayıdır, özellikle karşılaştırabileceğiniz bir şeyiniz yoksa! Bu sayı size bazı gerçekleri

gösterebilir. “Nedenlere bakmaksızın, bitirebileceğimizi düşündüğümüz ve gerçekten bitirdiğimiz

arasındaki yaklaşık fark işte burada.”

Neredeyse biten kullanıcı hikayesini ekleyecek miyiz? Neredeyse bitecekti, hikaye puanlarından

bitirdiğimiz kadarını takım hızına eklememiz gerekmez mi? Scrum, işleri tamamıyla, teslim edilebilir

şekilde bitirmek demektir(aslında Çevik yazılım geliştirme, Yalın üretimde, işlerin tamamıyla bitmesi

gerektiğini söyler). Neredeyse bitecek işin ürettiği değer sıfırdır. Bu konu hakkında daha fazla bilgi

için Donald Reinertsen’in Managing the Design Factory ya da Poppendieck’lerin bir kitabını almanızı

öneririm.

Takım hızını tahmin ederken hangi büyülerden yararlanıyoruz?

Takım hızını tahmin ederken en basit yol, takımın geçmiş Sprint’lerde tamamladığı işleri hesaplayarak

ortalamasını almaktır.

37

Bu teknik dünün hava durumu olarak bilinir. Bu teknik en azından birkaç Sprint koşmuş takımlar için

uygundur. Ayrıca geçmişe dönük verilerin tutulmuş olması gerekir. Sprint bazında takım hızı

hesaplandığında arada uçurumlar olmaz. Bir önceki Sprint ne yaptıysa bir sonraki Sprint de yaklaşık

olarak aynı hıza çıkabilir, tabi aynı takım üyeleri ve aynı çalışma koşullarında. Durum her zaman böyle

değildir.

Daha gelişmiş bir hesaplama şekliyse basit kaynak hesaplamasıdır. Diyelim ki dört kişilik bir takımla

üç haftalık(15 iş günü) bir Sprint planlıyoruz. Lisa iki gün izinli olacak, Dave sadece %50 erişilebilir

durumda ve bir gün izinli olacak. Bunların hepsini hesapladığımızda:

Bu Sprint için 50 adam/günlük kaynağımız var demektir.

Bu değer bizim ortalama takım hızımız mı? Hayır! Çünkü işlerin büyüklüğünü belirlerken kullandığımız

birim hikaye puanıdır. Bizim takım için hikaye puanı, ideal adam/gün’e neredeyse birebir karşılık

gelir. İdeal adam/gün oldukça verimlidir, takımın rahatsız edilmediği günler ki bu nadirdir. Ayrıca

Sprint Planlama’da konuşmadığımız fakat Sprint içinde acil gelen ve yapmamız gereken işler, takım

üyelerinin hastalanması gibi şeyler de vardır.

Yani bizim tahmini takım hızımız kesinlikle 50’nin altında olacaktır. Fakat ne kadar altında? Bunun için

odak çarpanını kullanırız.

Odak çarpanı takımın ne kadar odaklanabileceğine dair bir tahmindir. Düşük odak çarpanı, takımın

çok bölünebileceği anlamına gelmektedir.

Uyarı: Bu bölümden gerçekten nefret ediyorum. Sıradaki birkaç sayfayı parçalamak istiyorum.

Eğer merak ediyorsanız okuyabilirsiniz. Daha sonra neden nefret ettiğimi açıklayacağım.

Uyarı: Bu bölümden gerçekten nefret ediyorum. Sıradaki birkaç sayfayı parçalamak istiyorum.

Eğer merak ediyorsanız okuyabilirsiniz. Daha sonra neden nefret ettiğimi açıklayacağım.

38

Mantıklı bir odak çarpanına karar vermek için en iyi yol son birkaç Sprint’e bakmak ve ortalama

almaktır.

Gerçek takım hızı, son Sprint’te tamamlanan işlerin ilk büyüklük tahminlerinin toplamıdır.

Diyelim ki son Sprint üç kişiyle(Tom, Lisa ve Sam) üç haftada(45 adam/gün) 18 hikaye puanlık iş

bitirdik. Şimdi de gelecek Sprint için tahmini takım hızını hesaplamaya çalışıyoruz. İşleri bitirmek için

bu Sprint’lik Dave, takımla çalışacak. İzinler ve diğer konuları hesaba katarsak gelecek Sprint 50

adam/günlük kaynağımız var.

Gelecek Sprint için tahmin edilen takım hızı 20 hikaye puanıdır. Bunun anlamı Geliştirme Takımı

Sprint İş Listesi’ni oluştururken 20 hikaye puanı civarında işi Ürün İş Listesi’nden çekmelidir.

Bu durumda takım, toplamda 19 hikaye puanı olan ilk dört ya da toplamda 24 hikaye puanı olan ilk

beş iş maddesini çeker. Diyelim ki ilk dört maddeyi seçtiler sonuçta 19, 20’ye daha yakın bir değer.

Eğer işlerin bitmeyeceğine dair şüpheniz varsa daha az iş alın.

39

Dünün hava durumu kullanışlı bir tekniktir fakat bu tekniği sağduyu ile birleştirip kullanmalısınız. Eğer

son Sprint olağan dışı bir şekilde kötü(takımın çoğu bir hafta boyunca hasta olduysa) bir Sprint ise

gelecek Sprint bu kadar şanssız olmayacağınızı varsaymak doğru olabilir. Gelecek Sprint daha yüksek

bir odak çarpanı kullanabilirsiniz. Eğer takım süper hızlı yeni bir build makinesi aldıysa odak çarpanını

yine yükseltebilirsiniz. Eğer bu Sprint takıma yeni biri katılıyorsa odak çarpanını düşürmeniz gerekir.

Çünkü yeni gelenin eğitilmesi gerekmektedir.

Ne zaman mümkün olursa birkaç Sprint geriye doğru bakın ve o birkaç Sprint’in ortalamasını alın.

Peki ya takım ilk defa Scrum yapacaksa ve geriye dönük veri yoksa ne yapacağız? Benzer durumdaki

diğer takımların odak çarpanına bakın ve bir örnek seçin.

Peki ya örnek alabileceğiniz başka bir takım yoksa? Odak çarpanını tahmin edin. İyi haber tahmininiz

sadece ilk Sprint’e uygulanacaktır. İlk Sprint’ten sonra elinizde veriler olacak böylece odak çarpanını

ve tahmini takım hızını ölçebilir ve iyileştirebilirsiniz.

Yeni takımlar için kullandığım varsayılan odak çarpanı %70’tir. Çünkü takımlarımızın çoğunluğu en

sonunda %70 civarında bir noktaya eriştiler.

İşlerin Büyüklüğünü Belirlerken Hangi Tekniği Kullanıyoruz?

Yukarıda birkaç teknikten bahsettim. Birincisi içgüdüyle, ikincisi dünün havasına bakıp takım hızını

tahmin etme ve takımın sahip olduğu adam/gün sayısı ve odak çarpanını hesaplayarak takım hızını

tahmin etme tekniklerinden bahsettim.

Biz hangi tekniği kullanıyoruz?

Belirli ölçülerden bu tekniklerin hepsini beraber kullanıyoruz, çok zamanımızı almıyor.

Son Sprint’teki odak çarpanına ve gerçek takım hızına bakıyoruz. Başlayacağımız Sprint için elimizde

olan kaynağa bakarız ve odak çarpanını tahmin ederiz. Geçen Sprint belirlediğimiz odak çarpanını ve

bu Sprint tahmin ettiğimiz odak çarpanını karşılaştırırız ve gerekirse ayar çekeriz!

40

Sprint’e alacağımız kullanıcı hikayelerini belirlediğimiz zaman içgüdü kontrolü yaparım. Geliştirme

Takımı’ndan, rakamları görmezden gelmelerini rica ederim. Sprint’e alacağımız işleri bitirip

bitiremeyeceğimiz konusunda ne hissettiklerini sorarım. Eğer çok fazla iş çektiğimizi hissediyorlarsa

birkaç kullanıcı hikayesini çıkartırız ya da az iş çektiğimizi düşünüyorlarsa birkaç kullanıcı hikayesi

ekleriz.

Günün sonunda yaptığımız şey Sprint’e hangi kullanıcı hikayelerinin alınacağına karar vermektir.

Odak çarpanı, kaynak uygunluğu ve tahmin edilen takım hızı hedefe ulaşmak için sadece birer araçtır.

İndeks Kartlarını Neden Kullanıyoruz?

Sprint Planlama Toplantısı’nın çoğunda Ürün İş Listesi’nde bulunan kullanıcı hikayeleriyle ilgili işler

yaparız. Büyüklüklerini belirleriz, önceliklendiririz, netleştiririz ve daha küçük parçalara ayırırız.

Pratikte bunu nasıl yaparız?

Acı dolu bölümün sonu! Artık odak çarpanı kullanmıyorum çünkü çok zaman alıyor ve yanlış bir

his oluşturuyor. Ayrıca kullanıcı hikayeleri adam/gün biriminden tahmin etmeye zorluyor.

Artı odak çarpanı daha fazla insan = daha yüksek takım hızı yanlış varsayımına neden oluyor.

Bazen bu doğrudur, bazen doğru değildir. Eğer takıma yeni biri katılırsa ilk bir iki Sprint takım hızı

düşüş gösterir. Çünkü takım üyeleri yeni gelen kişinin takıma adaptasyonu için zaman harcarlar.

Eğer bir takım çok fazla büyürse(örneğin 10’dan fazla kişiden oluşursa) takım hızı kesinlikle düşüş

gösterir. Ayrıca odak çarpanının %100 olmamasının anlamı takımın odaklanma problemi

yaşadığını gösterir. Böyle bir ifade üst yönetime oldukça yanlış bir mesaj gönderebilir.

Bu nedenle odak çarpanı ve adam/gün olayını boş verin derim. Son birkaç Sprint’te ne kadar iş

bitirdiğinize bakın. Bunu yaparken hikaye puanlarını toplayabilirsiniz ya da bitirdiğiniz kullanıcı

hikaye sayısını hesaplayabilirsiniz eğer kullanıcı hikayelerinizin büyüklükleri birbirine yakınsa.

Daha sonra benzer bir sayıda kullanıcı hikayesini Ürün İş Listesi’nden çekebilirsiniz. Eğer

Sprint’inizde aksamalar olacağını tahmin ediyorsanız(örneğin iki kişinin eğitime gitme ihtimali

varsa) o zaman birkaç kullanıcı hikayesi daha az alın. Eğer elinizde geçmişe ait veri azsa o zaman

içgüdünüze daha çok güvenmelisiniz.

Eğer bunları yaparsanız Sprint Planlama Toplantılarınız kısalacak, daha verimli ve eğlenceli

olacaktır.

41

Takımlar excel’deki Ürün İş Listemizi projektörle duvara yansıtırlar. Bir kişi(genellikle Ürün Sahibi ya

da Scrum Master) klavyeyi alır ve kullanıcı hikayesini mırıldanır ve tartışmayı başlatır. Takım ve Ürün

Sahibi öncelikleri ve detayları konuştuktan sonra klavyedeki kişi excel ’deki kullanıcı hikayesini

günceller.

Nasıl, kulağa iyi geliyor değil mi? Hayır! Ve en kötüsü toplantının sonuna kadar takım bunun farkında

olmaz. Ayrıca listedeki bütün kullanıcı hikayelerinin üstünden geçmediklerini fark ederler.

Çok daha işe yarayan bir çözüm indeks kartlar oluşturmak, bunları bir duvara yapıştırmak ya da

büyük bir masaya herkesin görebileceği şekilde koymaktır.

Bilgisayar ya da projektöre göre bu daha kullanışlıdır. Çünkü:

● İnsanlar ayaktadırlar ve dolaşırlar. Böylece uyanık ve alarmda kalırlar.

● Herkes olaya daha çok dahil olduğu hissine sahip olur. Sadece klavyedeki kişi değil!

● Birden fazla kullanıcı hikayesi aynı anda güncellenebilir.

● Yeniden önceliklendirme kolaydır çünkü sadece indeks kartını ileri geri oynatmanız yeterlidir.

● Toplantıdan sonra indeks kartları takım odasına taşınabilir ve duvara asılabilir.

İndeks kartlarını ister elinizle yazın ya da bizim yaptığımız gibi kartları oluşturmak için basit bir script

çalıştırın.

Ah o acııııııı….

42

Not: Script’e blog’umdan erişebilirsiniz. http://blog.crisp.se/author/henrikkniberg

Önemli: Sprint Planlama Toplantısı’ndan sonra Scrum Master, indeks kartları baz alarak excel’deki

Ürün İş Listesi’ni günceller. Ürün İş Listesi’ni bu şekilde güncellemek zor bir yöntem fakat indeks

kartlarını kullanarak planlama yapmak oldukça verimli. Gülü seven dikenine katlanır.

“Önem” kolonu excel’deki Ürün İş Listesi’nde tutulur. Aynı zamanda fiziksel indeks kartlara da

yazarız. En önemli kullanıcı hikayeleri en solda önemi daha az kullanıcı hikayeleri daha sağda olacak

şekilde sıralama yaparız. Kartları duvara yapıştırdıktan sonra önem derecesini görmezden

gelebilirsiniz çünkü fiziksel sıralamayı aslında önem derecesini temel alarak yaparız. Eğer Ürün Sahibi

iki kullanıcı hikayesinin yerini değiştirirse kağıt üzerindeki önem derecesini güncellemekle zaman

kaybetmeyiz fakat excel’deki tablomuzu güncelleriz.

Eğer kullanıcı hikayeleri daha küçük parçalara bölünürse(gerçekleştirilecek işlere) ilgili işin ne kadar

zaman alacağını tahmin etmek daha kolaydır. Biz aktivite terimini kullanırız çünkü İsveççe’de iş(task)

bambaşka bir anlama geliyor. Ayrıca bu aktiviteyi de indeks kartlarla gerçekleştirmek oldukça

kolaydır. Takım, çiftlere ayrılarak kullanıcı hikayelerini paralel şekilde daha küçük işlere ayırabilir.

Script’i bulmanın en kolay yolu “index card generator” diye Google’da aramaktır. Bu eski script’in

hala kullanıldığına inanamıyorum. Bazı güzel insanlar bu script’i Google Spreadsheet’e taşımaya

da yardım ettiler. Eli ayağı düzgün her Ürün İş Listesi yönetim aracı yazdırma özelliğine sahiptir.

Farklı araçlarla deney yapın ve içinde bulunduğunuz durumda sizin işinize en çok hangisi yarıyor

öğrenin. Dikkat etmeniz gereken en önemli nokta aracı sürecinize adapte etmenizdir, süreci

aracınıza göre adapte etmemelisiniz!

Önem derecesini boş verin. Daha önce birkaç defa söylediğimi biliyorum. Kendimi çok mu tekrar

ediyorum? Kendimi tekrar mı ediyorum? :)

43

İndeks kartlarının altına küçük yapışkan kağıtlar yapıştırarak bu aktiviteyi gerçekleştiririz. Her bir

yapışkan kağıt yapılması gereken bir iş olduğu anlamına gelir.

Kullanıcı hikayelerini işlere ayırdıktan sonra excel ’de bulunan Ürün İş Listesi’ni güncellemeyiz. Bunun

iki nedeni vardır:

İşlere bölme işi biraz gelip geçici bir iştir. Sprint içinde işin içine girdikçe yeni şeyler ortaya çıkabilir.

Sürekli olarak excel’de bulunan tabloyu güncellemek yönetimsel olarak çok zor olur ve çok zaman

alır.

Ürün Sahibi, teknik detaylara dahil olmak zorunda değildir.

İndeks kartlarının kullanıldığı gibi yapışkan kağıtlarda Sprint İş Listesi’ni oluştururken kullanılabilir.

44

Bitti Tanımı

Ürün Sahibi’nin ve Geliştirme Takımı’nın net ve anlaşılır bir Bitti Tanımı üzerinde fikir birliğine

varması çok önemlidir.

Kodun tamamı kaynak sisteme gönderildiğinde bir kullanıcı hikayesi bitmiş oluyor mu? Yoksa bu kod

test ortamına gönderilip entegrasyon testini geçtikten sonra mı bitmiş oluyor? Ne zaman gerekliyse

bir Bitti Tanımı oluşturur ve kullanırız, “Test ortamına teslim yapıldı ve kullanıcı kabul testine hazır”.

Bazen de Hazır Tanımını kullanırız, “üretim ortamına alınmaya hazır”.

Başlangıçta bunun için detaylı bir kontrol listesi kullandık. Şimdilerde genellikle Scrum Takımı’ndaki

testçi kullanıcı hikayesinin Bitti Tanımı’na uyup uymadığını söylüyor.

Ayrıca anladık ki tüm kullanıcı hikayelerine aynılarmış gibi davranamayız. “Kullanıcı formu sorgusu”

adlı kullanıcı hikayesi, “manuel operasyonlar” adlı kullanıcı hikayesinden çok farklı şekilde

çözümlenmelidir. “Bitti” Tanımı, özetle operasyon takımı tarafından kabul edilen anlamına gelebilir.

Bu nedenle ortak anlayış, bir kontrol listesinden daha iyidir.

Eğer Bitti Tanımı konusunda kafanız sürekli karışıyorsa(başlangıçta bizim oldukça karışıyordu) o

zaman her bir kullanıcı hikayesinde “Bitti Tanımı” için bir alan açabilirsiniz.

Planlama Poker ile Efor Tahmini

Efor tahmini yapma bir takım aktivitesidir. Her bir takım üyesi her bir kullanıcı hikayesinin eforunun

tahmin edilmesi işine katılır. Neden?

● Planlama yaparken kullanıcı hikayesinin hangi bölümünü kimin geliştireceğini bilmeyiz.

● Kullanıcı hikayeleri normalde farklı uzmanlık alanlarından(kullanıcı ara yüzü tasarımı,

kodlama, test vb..) olan birkaç kişi tarafından geliştirilir.

● Efor tahminini yapabilmek için takım üyelerinin kullanıcı hikayesinin ne olduğunu anlaması

gerekir. Herkesin kullanıcı hikayelerinin büyüklüklerini tahmin etmesini rica ederek her bir

ÇOOOOKK önemlidir.

Tamam, kabul ediyorum. Bu, biraz saçma. Somut bir kontrol listesi daha kullanışlıdır. Sadece çok

uzun olmamasına dikkat edin. İnsanların unuttukları şeylere odaklanın, “teslim notlarını

güncellemek”, “teknik borcun ödenmesi” ya da “son kullanıcıdan geribildirim al” gibi şeylere.

45

kullanıcı hikayesinin aslında ne işe yaradığını anlamasını sağlarız. Bu yaklaşım takım

üyelerinin Sprint içinde birbirlerine yardım etmelerini sağlar. Ayrıca kullanıcı hikayesiyle ilgili

önemli soruların erkenden sorulmasını da sağlar.

● Geliştirme Takımı’ndaki herkesin kullanıcı hikayelerine büyüklük vermesini istediği miz zaman

tutarsızlıkları keşfederiz. Aynı kullanıcı hikayesi için iki kişi birbirinden çok farklı düşüncelere

sahip olabilir. Böyle şeyleri erken keşfetmek ve konuşmak sonra bulmaktan daha iyidir.

Eğer takıma işlerin büyüklüğünü sorarsanız genellikle kullanıcı hikayesini iyi bildiğini düşünen biri

ağzından bir şeyler kaçıracaktır.

Bunu önlemek için mükemmel bir teknik var. Adı poker planlama, galiba Mike Cohn tarafından

geliştirildi.

Her bir takım üyesi yukarıda gösterilen 13 karta sahiptir.

Bu poker kartlarını planningpoker.crisp.se adresinde satıyoruz. Şimdi resimde gördüklerinizden

daha güzeller. Gerçi araştırırsanız daha ucuzunu bulursunuz. Ayrıca bu sitede çok güzel bir şey

daha satıyoruz. Adı Jimmy Cards. Evet, iş arkadaşımızla kartların ismini belirlerken biraz sorun

yaşadık. Ama ne yaparsınız. Bir göz atın!

Mike, James Grenning’ten öğrendiğini söyledi. Muhtemelen James’te fikri başkasından aldığını

söyleyecektir. En iyisini bunu düşünmeyin. Hepimiz devlerin omuzlarında yükseliriz. Belki hepimiz

birbirinin omuzlarında yükselen birer cüceyizdir. Siz ne demek istediğimi anladınız!

46

Kullanıcı hikayesinin büyüklüğü tahmin edileceği zaman takım üyeleri seçimlerini gösteren kartı

seçerler ve yüzü kapalı bir şekilde masaya koyarlar. Bütün takım üyeleri hazır olduğunda takım

üyelerinin seçtiği kartlar aynı anda gösterilir. Böylece her bir takım üyesi ilk önce kendi kendine

düşünmüş olur ve bir başkasının tahmininden etkilenmemiş olur.

Eğer iki tahmin arasında büyük bir tutarsızlık varsa takım aradaki farkın neden kaynaklandığını

konuşur. Kullanıcı hikayesi kapsamında yapılacak işi ortak bir resimde birleştirmeye çalışır. Belki

takım üyeleri kullanıcı hikayesini daha küçük işlere bölerler. Daha sonra Geliştirme Takımı kullanıcı

hikayesinin büyüklüğünü yeniden tahmin eder. Bu döngü takım üyelerinin seçimleri aynı olana dek

tekrarlanır.

Takım üyelerinin kullanıcı hikayesinde gerçekleştirilecek bütün işler için büyüklük tahmini yapmaları

hatırlatılmalıdır. İşin sadece kendiyle ilgili bölümü için tahminde bulunmamalıdırlar. Örneğin bir testçi

işi sadece test etmeyi düşünmemelidir.

Sayı dizisi doğrusal değildir. Örneğin 40 ve 100 arasında hiçbir şey yoktur. Neden?

Büyük kullanıcı hikayelerinde yanlış tahmini engellemek içindir. Eğer bir kullanıcı hikayesinin

büyüklüğü yaklaşık olarak 20 hikaye puanı olarak belirlenmişse onun 18’mi 21’mi olduğunu

konuşmak önemsizdir. Bildiğimiz tek şey bunun büyük bir kullanıcı hikayesi olduğudur. Yani 20 bizim

salladığımız bir sayıdır.

Daha detaylı tahminler mi istiyorsunuz? Kullanıcı hikayelerini daha küçük kullanıcı hikayelerine bölün.

Ayrıca 5 ve 2’yi birleştirerek 7 elde edemezsiniz. Bu aldatmayı gerçekleştiremezsiniz. Ya 5’i ya da 8’i

seçmek zorundasınız. Listede 7 yok!

Bazı özel kartlar:

- 0: Bu kullanıcı hikayesi hali hazırda bitirildi ya da bu kullanıcı hikayesinde yapılacak pek bir

şey yok, sadece birkaç dakikalık bir iş demektir.

- ?: Hiç bir fikrim yok!

- Kahve Kupası: Düşünmekten yoruldum. Ara verelim.

47

Kullanıcı Hikayelerini Netleştirme

Sprint Değerlendirme Toplantısı’nda takım geliştirdiği yeni bir özelliği gösterir ve Ürün Sahibi

somurtur ve şunu söyler: “Bu çok güzel fakat benim istediğim şey değil!”

Ürün Sahibi’nin kullanıcı hikayesinden anladığıyla Geliştirme Takımı’nın anladığının aynı şey

olduğundan nasıl emin olabilirsiniz? Geliştirme Takımı’nın her bir üyesinin aynı anlayışa sahip

olmasını nasıl sağlarsınız? Sağlayamazsınız! En bariz yanlış anlaşılmaları belirlemek için bazı basit

teknikler vardır. En basit teknik her bir kullanıcı hikayesi için Ürün İş Listesi’nde bulunan alanların

gerekli bilgilerle doldurulduğundan emin olmaktır.

Örnek 1

Geliştirme Takımı ve Ürün Sahibi, Sprint Planı oluştuğu için mutlular ve toplantıyı bitirmeye hazırlar.

Scrum Master der ki: “Bir dakika! ‘Kullanıcı ekle’ adındaki kullanıcı hikayesine hikaye puanı

verilmemiş. Hadi bu kullanıcı hikayesine puan verelim.” Birkaç poker turundan sonra Geliştirme

Takımı 20 hikaye puanında anlaşır ve Ürün Sahibi: “Neeeeeee” diye ayağa fırlar. Birkaç dakikalık

ateşli bir tartışmadan sonra Geliştirme Takımı’nın ‘kullanıcı ekle’ adlı kullanıcı hikayesinin kapsamını

yanlış anladığı ortaya çıkar. Takım, kullanıcının eklendiği, silindiği, arama yapılabilen güzel bir ara

yüze sahip bir ekran düşünmüştür. Halbuki Ürün Sahibi veri tabanına script’le kullanıcı eklenmesini

kastetmiştir. Bir tur poker daha oynanır ve 5 hikaye puanında anlaşılır.

Örnek 2

Geliştirme Takımı ve Ürün Sahibi, Sprint Planı oluştuğu için mutlular ve toplantıyı bitirmeye hazırlar.

Scrum Master der ki: “Bir dakika! ‘Kullanıcı ekle’ adlı kullanıcı hikayesinin gösterimini nasıl

yapacağız?”

Bazıları buna Hazır Tanımı diyorlar. Yani Bitti Tanımı, bir işin bitirilmesi için bir kontrol listesiyken

Hazır Tanımı, bir işin Sprint’e alınması için gerekli olanların bulunduğu bir kontrol listesidir.

Bir şirket çok havalı bir fikir geliştirdi. Palavraya Hayır kartları(estimation.lunarlogic.io). Sadece üç

kart var.

1(One)

TFB(too f*cking big)

NFC(no f*cking clue)

Çok havalı! Keşke benim aklıma gelseydi. Gerçi Kahve Kupası fikri benden çıktı ama neyse!

48

Bir süre mırıldanmadan sonra biri ayağa kalkar ve “ilk önce web sayfasına giriş yaparız daha sonra…”

derken Ürün Sahibi araya girer.

“Web sayfasına giriş yapmak mı?! Hayır, hayır. Bu işlevsellik web sayfasının bir parçası değil.

Yöneticiler rolündeki kullanıcıların girişini sağlayabilmek için veri tabanına o kullanıcıyı kaydeden

basit bir SQL cümleciği sadece.”

Bir kullanıcı hikayesinin “Nasıl gösterimi yaparız?” tanımı çok kısa olabilir ve olmalıdır. Yoksa Sprint

Planlama Toplantısı’nı zamanında bitiremezsiniz. Temelde en çok kullanılacak işlevselliğin manuel

olarak üst seviye bir testidir. “Bunu yap, daha sonra şunu ve sonucu doğrular.”

Bu basit tanımın büyük yanlış anlaşılmaları önlediğini çok gördüm. Yanlış anlaşılmaları önceden

belirlemek iyi bir şeydir, değil mi?

Kullanıcı Hikayelerini Küçük Parçalara Bölme

Kullanıcı hikayeleri çoook büyük ya da çoook küçük olmamalıdır. Eğer 0.5 büyüklüğünde bir sürü

kullanıcı hikayeniz varsa büyük ihtimalle detayları yönetmenin(micro management) kurbanı

olacaksınız. Öte yandan 40 hikaye puanlık bir kullanıcı hikayesinin bir bölümünün bitmesi ve bir

bölümünün bitmemesi gibi bir risk vardır. Bu, şirketinize bir değer kazandırmaz ve yönetimi artırır.

Ayrıca eğer geliştirme hızınız 70 hikaye puanıysa ve en öncelikli iki kullanıcı hikayeniz 40’ar hikaye

puanından 80 hikaye puanı ediyorsa planlamanız zorlaşacaktır. Önünüzde iki seçenek bulunur: Ya

takım hızınızdan daha az iş alacaksınız(kullanıcı hikayelerinden birini seçeceksiniz) ya da takım

hızınızdan daha fazlasını alacaksınız(kullanıcı hikayelerinin ikisini de Sprint’e alacaksınız).

Bir kullanıcı hikayesini her zaman küçük parçalara bölebilirsiniz. Sadece şuna dikkat edin küçük

kullanıcı hikayeleri iş değeri üretiyor olsun.

Kullanıcı hikayelerinin en az iki en çok sekiz adam/gün aralığında olmaları için uğraşırız. Normal bir

takım için takım hızımız 40-60 hikaye puanı aralığındadır. Bu da demektir ki bir Sprint’e ortalama 10

Bu tekniği beğeniyorum ve bir kullanıcı hikayesinin belirsiz olduğunu düşündüğüm zaman hala

kullanıyorum. Bu tekniğe alternatif olarak kullanıcı hikayesi altında yapılacakları çizerek

anlatmaya çalışıyorum ya da kabul kriterlerinin bir listesinin oluşturulmasını sağlıyorum. Kullanıcı

hikayesini problemin çokta detaylı olmayan bir ifadesi olarak ve bu kullanıcı hikayesi bittiğinde nasıl görüneceğine dair somut bir örnek olarak “Bitti Tanımı”nı düşünün.

49

kullanıcı hikayesi alabiliriz. Kimi zaman 5 kimi zaman 15 kullanıcı hikayesi aldığımız olur. Bu sayı,

Scrum Duvarı’na yapıştırılan kartlar için yönetilebilir bir sayıdır.

5-15 aralığında kullanıcı hikayesi almak kullanışlı bir rehber olabilir. 5’ten az olması kullanıcı

hikayelerinin bir Sprint için büyük olduğu anlamına gelir. 15’ten fazla kullanıcı hikayesi olmasıysa

takımın Sprint’e çok iş aldığı ve bitiremeyebileceği anlamına gelir(ya da kullanıcı hikayeleri çok küçük

ve detaylar takımı çok uğraştıracak demektir).

Kullanıcı Hikayelerini İşlere Bölme

Bir dakika… “Kullanıcı hikayesi” ve “İşler” arasındaki fark nedir? Oldukça değerli bir soru.

Aradaki fark oldukça basittir. Kullanıcı hikayeleri teslim edildiğinde değer katan ve Ürün Sahibi’nin

önemsediği şeyler. Teslim edildiğinde değer katmayan ve Ürün Sahibi’nin önemsemediği şeyler

İşler(Task’lar) olarak düşünülebilir.

Bir kullanıcı hikayesini daha küçük kullanıcı hikayelerine bölme örneği:

5-15 aralığında kullanıcı hikayesi almak kullanışlı bir rehber olabilir. 5’ten az olması kullanıcı

hikayelerinin bir Sprint için büyük olduğu anlamına gelir. 15’ten fazla kullanıcı hikayesi olmasıysa

takımın Sprint’e çok iş aldığı ve bitiremeyebileceği anlamına gelir(ya da kullanıcı hikayeleri çok küçük ve detaylar takımı çok uğraştıracak demektir).

50

Bir kullanıcı hikayesini işlere(task’lara) bölmenin örneği:

İlginç birkaç gözlem:

● Yeni Scrum Takımları kullanıcı hikayelerini işlere bölmeye ve bunun için zaman harcamaya

direnç gösterirler. Bazıları bunun waterfallvari bir yaklaşım olduğunu hissederler.

● Kullanıcı hikayelerini net bir şekilde anlayabilmek için bu kırılımı önceden yapmak sonradan

yapmak kadar kolaydır.

● Bu şekilde bir kırılım ek işleri ortaya çıkarır ve efor tahminlerinin artmasına neden olabilir.

Ayrıca daha gerçekçi bir planlamaya sahip olmamızı sağlar.

● Bu şekilde kırılım yapmak Günlük Scrum Toplantıları’nın daha verimli olmasını sağlar.(Günlük

Scrum Toplantıları’nı Nasıl Yaparız bölümüne bakınız)

● Kırılımlar doğruya yakın olmasa ve değişse bile yukarıdaki avantajlar geçerlidir.

Sprint Planlama Toplantısı’nı belirlenen sürede gerçekleştirmeye çalışırız. Eğer gerçekleştiremiyorsak

toplantıyı bitiririz.

Not: TDD yapıyoruz ve ilk işimiz “başarısız(fail eden) bir test yaz” oluyor. Son işimizse refactor(kod

okunurluğunu geliştir ve tekrar eden kodları sil) yap.

Kullanıcı hikayelerini işlere bölmek bağımlılıkları ortaya çıkarmak için çok iyi bir fırsattır. Örneğin:

“Üretim ortamındaki loglara erişmemiz gerekiyor” ya da “İK’dan Jim’in yardımına ihtiyacımız var”.

Böylece bu bağımlılıklarla nasıl başa çıkmanın yollarını ararız. Belki Jim’i ararız ve Sprint içinde

bize zaman ayırabilecek mi öğreniriz. Bağımlılığı ne kadar önceden keşfederseniz Sprint içinde problem yaşama olasılığınızı o kadar azaltırsınız!

51

Günlük Scrum için Yer ve Zaman Belirleme

Sprint Planlama Toplantısı’nın çokça unutulan bir çıktısı Günlük Scrum Toplantısı’nın ne zaman ve

nerede yapılacağını belirlemektir. Bu olmadan Sprint’iniz kötü bir başlangıca sahip olacaktır. İlk

Günlük Scrum Toplantısı herkesin işe nereden başlayabileceğine dair karar verdiği yerdir.

Ben sabahları Günlük Scrum yapmayı tercih ederim. Fakat öğlen ya da akşamüzeri Günlük Scrum

Toplantısı yapmadığımı da itiraf etmeliyim.

Öğleden sonra yapılan Günlük Scrum Toplantıları’nın dezavantajları: Sabah işe geldiğinizde dün

insanlara bugün ne yapacağınızı söylediğinizi hatırlamak zorundasınızdır.

Sabah yapılan Günlük Scrum Toplantıları’nın dezavantajları: Sabah işe geldiğinizde dün ne

yaptığınızı hatırlamak zorundasınızdır. Böylece insanlara bilgi verebilesiniz.

Bence ilk dezavantaj daha kötü çünkü ne yapacağınız ne yaptığınızdan daha önemlidir.

Bizim prosedürümüz kimsenin esnemediği en erken zamanı seçmektir. Genellikle 9:00, 9:30 ya da

10:00. En önemli şey takımdaki herkesin kalbinin tümüyle kabul etmesidir.

Çizgiyi Nereye Çekmeliyiz?

Zaman akıp gidiyor. Sprint Planlama’da yapmak istediğimiz bir sürü şey var. Eğer zamanımız bitiyorsa

neleri yapmaktan vazgeçmeliyiz?

Ben aşağıdaki öncelik listesini kullanıyorum:

Öncelik 1: Sprint Hedefi ve demo tarihi. Sprint’e başlayabilmeniz için bilmeniz gerekenler bu

kadardır. Takım hedefe, bir bitiş tarihine sahiptir ve Ürün İş Listesi’ndeki maddeleri çalışmaya

başlayabilirler. Evet, berbat bir durum ve yarın yeni bir planlama yapmayı düşünebilirsiniz. Fakat

Sprint’e bir an önce başlamanız gerekiyorsa bu kadar bilgiyle de başlayabilirsiniz. Dürüst olmak

gerekirse bu kadar az bilgiyle hiç Sprint’e başlamadım. Ama başlamanız gerektiyse yapılabilir.

Öncelik 2: Takım’ın Sprint’e aldığı işlerin listesi.

Öncelik 3: Sprint’e alınan işlerin büyüklük tahmini.

Öncelik 4: Sprint’e alınan her işin demosu nasıl yapılacak bilgisi.

Öncelik 5: Takım hızı ve kaynak hesaplaması(Sprint planlamanızın gerçekliğini kontrol etmek için).

Takım üyelerinin listesi ve projeye katılım oranlarının bulunduğu bir liste.

Şimdi yapıyorum. Fena değil. Takımın seçmesine izin verin. Eğer emin değilseniz deney yapın. Birçok takım sabah yapmayı tercih ediyor.

52

Öncelik 6: Günlük Scrum için yeri ve zamanı belirleyin. Karar vermek sadece 1 dakika sürer. Fakat

zamanınız bittiyse Scrum Master belirleyebilir ve herkesi bilgilendiren bir e -posta gönderebilir.

Öncelik 7: Kullanıcı hikayeleri küçük işlere bölünür. Kullanıcı hikayelerini işlere bölme işi Günlük

Scrum içinde de yapılabilir fakat bu yaklaşım Sprint’in akışını bozabilir.

Teknik Kullanıcı Hikayeleri

İşte karmaşık bir konu: Teknik kullanıcı hikayeleri ya da Ürün Sahibi’ne değer katmayan fakat

yapılması gereken işler ya da işlevsel olmayan işler.

Yapılması gereken fakat Ürün Sahibi’ne iş değeri katmayan işlerden bahsediyorum, herhangi bir

kullanıcı hikayesiyle direkt olarak bağlantılı olmayan işler.

Bu işlere biz “teknik kullanıcı hikayesi” diyoruz.

Örnek:

● Sürekli teslim için ana bilgisayar kurulumu

Neden yapılmalı: Çünkü geliştiricilere çok zaman kazandırır ve her iterasyon sonunda

entegrasyon problemlerinin oluşması riskini azaltır.

● Sistem tasarımının oluşturulması

Neden yapılmalı: Çünkü geliştiriciler sistem tasarımının tümünü hatırlamayabilirler,

unutabilirler. Bu da doğru kodun yazılmasının önünde engel olabilir. Herkeste aynı fikir olması için

büyük resmin olduğu bir doküman olmalıdır.

Ne zaman biri “işlevsel olmayan işlerden” bahsetse kıkırdamadan duramıyorum. Kulağa işlevi

olmayan işler gibi geliyor.

Basit tutun ve üst seviye bir şey hazırlayın, en fazla 5 dakika zaman harcayın. Takım üyelerinin

katılımı açısından bir önceki Sprint’e göre büyük bir değişiklik olup olmadığını sorun. Eğer yoksa

dünün hava durumunu* kullanın eğer Takım üyelerinin Sprint’e katılımlarında değişiklik varsa

buna göre Sprint’e alınan işlerde değişiklik yapın.

* Dünün hava durumu deyimi şu anlama gelmektedir: Eğer dün hava yağmurlu olduysa ve

bulutlar dağılmadıysa yani hava da bir değişiklik olmadıysa dün giyindiğiniz şekilde

giyinmelisinizdir. Bugünde şemsiyenizi yanınıza almalısınız demektir. Özetle bir önceki Sprint de

bitirdiğiniz kadar iş almalısınız!

53

● Veri erişim katmanının iyileştirilmesi

Neden yapılmalı: Çünkü veri erişim katmanı oldukça karmaşıklaşmaya başladı. Herkesin aklını

karıştırıyor ve gereksiz hatalar yapılmasına neden oluyor. Kodun temizlenmesi herkesin zaman

kazanmasını sağlar ve sistemin sağlamlığını artırır.

● Jira’yı yeni sürüme geçirme

Neden yapılmalı: Şuan kullandığımız versiyonda birçok problem var ve yavaş, Jira’yı

güncellemek herkese zaman kazandırır.

Bu kullanıcı hikayeleri normal mi? Yoksa hiçbir kullanıcı hikayesiyle ilgisi olmayan teknik işler mi?

Bunları kim önceliklendirecek? Ürün Sahibi bu işe dahil edilmeli mi?

Teknik kullanıcı hikayeleriyle baş edebilmek için birçok deney yaptık. Tıpkı diğer kullanıcı hikayeleri

gibi birinci sınıf kullanıcı hikayesi gibi düşündük. Bu bizim işimize yaramadı. Ürün Sahibi, Ürün İş

Listesi’ni önceliklendirdiği zaman elmaları ve portakalları karşılaştırıyormuş gibi oldu. Belli

nedenlerden teknik kullanıcı hikayelerine düşük öncelikler verilir. “Evet arkadaşlar, sürekli teslim ana

bilgisayarının kurulmasının çok önemli olduğunu biliyorum fakat önce gelir getirecek işleri yapalım,

ne dersiniz? Daha sonra sürekli teslim lolipopunuzu ekleyebilirsiniz, tamam mı?”

Bazı durumlarda Ürün Sahibi haklıdır fakat genelde haksızdır. Ürün Sahibi’nin her zaman bu kararı

verebilecek yetkinlikte olamayabileceğine karar verdik. Bu nedenle biz aşağıdaki yolu izliyoruz:

1. Teknik kullanıcı hikayelerini görmezden geliriz. Teknik bir kullanıcı hikayesini değer getiren

normal bir kullanıcı hikayesine dönüştürmeye çalışırız. Bu şekilde Ürün Sahibi elmalar ve

portakalları karşılaştırmamış olur.

2. Eğer teknik kullanıcı hikayesini normal bir kullanıcı hikayesine dönüştüremiyorsak yapılacak

teknik iş normal bir kullanıcı hikayesinin içinde bir iş(task) olarak yapılabilir mi diye

düşünürüz. Örneğin DAO katmanının iyileştirilmesi “kullanıcı ekleme” hikayesinin altında bir

iş olarak yapılabilir mi? Sonuçta “kullanıcı ekleme” hikayesi DAO katmanını da içerir.

3. Eğer yukarıdaki iki madde de başarısız olursa teknik kullanıcı hikayesi olarak tanımlayın ve

teknik işler için ayrı bir liste tutun. Ürün Sahibi’nin bu listeyi görmesine izin verin fakat

değişiklik yapmasına izin vermeyin. “Odak çarpanını” ve “tahmini takım hızını”

54

parametrelerini kullanarak Ürün Sahibi’yle pazarlık yapın ve teknik kullanıcı hikayelerini

gerçekleştirebilmek için Sprint içinde zaman kazanın.

Buna çok benzer bir diyalog Sprint Planlama Toplantıları’mızdan birinde gerçekleşmişti:

Takım: Yapmamız gereken bazı teknik işler var. Zamanımızın %10’ununu bu işlere ayırmak istiyoruz.

Odak çarpanını %75’ten %65’e indirebilir miyiz?

Ürün Sahibi: Tabi kiiiii hayır! Zamanımız yok!

Takım: Peki, geçen Sprint’e bak.(Tüm başlar takım hızının yazıldığı yere döner). Tahmin ettiğimiz

takım hızımız 80’di ve gerçek takım hızımız 30’du, değil mi?

Ürün Sahibi: Aynen! Bu nedenle teknik işlere ayıracak vaktimiz yok, gelir elde edebileceğimiz yeni

işlevselliklere ihtiyacımız var.

Takım: Takım hızımızın bu kadar düşük olmasının nedeni uyumlu teslimleri bir araya getirip test

etmeye çok fazla zaman harcamamızdır.

Ürün Sahibi: Eeee, yani?

Takım: Bu konuda bir şey yapmazsak takım hızımız böyle kötü olmaya devam edecektir.

Ürün Sahibi: Eeee, yani?

Takım: Önerimiz bu Sprint’in %10’luk zamanımızı ayırıp sürekli teslim ana bilgisayarını kurar ve

entegrasyonla ilgili diğer sıkıntıları hallederiz. Bunu yapmak takım hızımızı en az %20 artıracak.

Ürün Sahibi: Hadi canım, gerçekten mi? Peki geçen Sprint bunu neden yapmadık?!

Takım: Çünkü sen yapmamızı istemedin…

Ürün Sahibi: Hmm peki. O zaman bu Sprint yapalım.

Elbet diğer seçenek Ürün Sahibi’ni bu işin dışında tutmaktır. Fakat önce ortak anlayışa ulaşmamak

için bir bahane yok.

Teknik kullanıcı hikayelerinin mükemmel bir model olduğunu düşünüyorum ve hala kullanıyorum.

Küçük teknik hikayeleri günlük işlerin içinde yaparız. Büyük teknik hikayeleri yazar ve teknik

kullanıcı hikayeleri listesine ekleriz. Ürün Sahibi bu hikayeleri görebilir fakat bu hikayeler takım

tarafından yönetilir. Geliştirme Takımı ve Ürün Sahibi Sprint’in %10-20 zamanını bu hikayelere

ayırma konusunda anlaşırlar. Odak çarpanı ya da zaman çizelgesi gibi detaylı izleme modellerine

gerek yok sadece içinizden geçen tahminle belirleyin. Retrospektif toplantısında sorun: ”Sizce bu

Sprint’te teknik kullanıcı hikayelerine kabaca ne kadar zaman harcamışızdır. Sizce doğru mu

yaptık?”

55

Eğer Ürün Sahibi yetkin ve mantıklı biriyse(eğer öyle biri olursa şanslıyız demektir) mümkün

olduğunca her şeyden haberdar etmenizi ve tüm öncelikleri onun belirlemesine izin vermenizi tavsiye

ederim. Şeffaflık, Scrum’ın ana değerlerinden biri, değil mi?

Hata Takip Sistemi mi? Ürün İş Listesi mi?

İşte zor bir konu! Ürün İş Listesi için Excel mükemmel bir araçtır. Fakat yine de hata takip sistemine

ihtiyacınız vardır ve Excel bu konuda başarılı değildir. Bunun biz Jira kullanırız.

Peki Jira’da bulunan işleri Sprint Planlama Toplantısı’na nasıl dahil ederiz? Demek istediğim şey

hataları görmezden gelmek ve sadece kullanıcı hikayelerine odaklanmak olabilecek bir şey değildir.

Birkaç denememiz oldu:

1. Ürün Sahibi Jira’da bulunan önceliği en yüksek işlerin çıktısını alır. Bunları Sprint Planlama

Toplantısı’na getirir ve diğer kullanıcı hikayeleriyle beraber duvara yapıştırır. Jira’daki işlerin

önceliğini belirlerken sadece Jira’da bulunan hatalarla karşılaştırmaz, elimizde bulunan

kullanıcı hikayeleriyle de öncelik karşılaştırmasında bulunur.

2. Ürün Sahibi, Jira’da seçtiği işler için kullanıcı hikayeleri oluşturur. Örneğin; “Arka ofis

raporlarındaki en önemli hataların düzeltilmesi: Jira-124, Jira-126 ve Jira-180”

3. Hataları düzeltme Sprint’e dahil olmama gibi düşünülür. Geliştirme Takımı odak çarpanını

düşük(%50) tutar. Böylece hataları çözmek için yeterli zaman ayırdıklarından emin olurlar. En

basit haliyle Jira’da bulunan hatalar için takımın belirli bir zaman ayıracağı varsayılır.

4. Ürün İş Listesi maddesi Jira’ya eklenir. Hata, herhangi bir kullanıcı hikayesi gibi düşünülür.

Bu strateji bizim için en iyisi diyemem. Aslında takımdan takıma ve Sprint’ten Sprint’e değişiklik

gösteriyor. Birinci seçenekten yanayım, güzel ve basit.

Sekiz yıl sonra aynı fikirdeyim. Sadece bir tane iyi pratik yoktur. Her strateji içinde bulunduğunuz

şartlara göre iyi olabilir. Sizin için en iyi stratejiyi bulana kadar deney yapın!

Eğer Ürün Sahibi’yle teknik kullanıcı hikayeleri, kalite ve teknik borç hakkında açık bir konuşma

yapamazsanız o zaman çözmeniz gereken daha büyük bir sorununuz var demektir. Bunun bir

göstergesi Ürün Sahibi’nden bilgi saklamanızdır. Her konuşmaya Ürün Sahibi’ni dahil etmek

zorunda değilsiniz fakat Takım ve Ürün Sahibi arasındaki ilişkinin temelinde güven ve saygı

olmalıdır. Bu olmadan geliştirdiğiniz ürünün başarılı olması olasılık dışı bir şeydir.

56

Sprint Planlama Toplantısı Sonunda Biter

Sprint Planlama Toplantısı’yla ilgili bölümün bu kadar uzun olacağını düşünmemiştim. Sanırım Sprint

Planlama’nın Scrum’da yaptığınız en önemli şey olduğuna dair görüşümün bir kanıtı bu olabilir. Doğru

yapabilmek için çok fazla efor harcayın böylece kalanı çok daha kolay olacaktır.

Eğer herkes(Geliştirme Takımı’nın tüm üyeleri ve Ürün Sahibi) yüzünde bir gülümsemeyle ayrılıyorsa

ve ertesi sabah yüzünde bir gülümsemeyle uyanıyorsa ve ilk Günlük Scrum’larını gülümseyerek

yapıyorlarsa başarılı olmuştur.

Daha sonra elbet her şey kötü gidebilir fakat en azından bunun için Sprint’in planlamasını

suçlayamazsınız! :)

Ya da tam tersi. Diğer her şeyi iyi yapın. Sprint Planlama Toplantısı çantada keklik olsun! :)

57

Bölüm

Beş

İletişimi Nasıl Gerçekleştiriyoruz?

Neler olduğuna dair tüm şirketi haberdar etmek çok önemlidir. Aksi takdirde insanlar şikayet

edeceklerdir ya da daha kötüsü neler olduğuna dair hatalı varsayımlarda bulunacaklardır.

Bunun için “Sprint Bilgi Sayfası” kullanırız.

Bazen her bir kullanıcı hikayesinin nasıl demo yapılacağına dair bilgi de ekleriz.

Sprint Planlama Toplantısı’ndan hemen sonra Scrum Master bu sayfayı oluşturur, wiki’ye koyar ve

tüm şirkete e-posta gönderir.

58

Ayrıca wiki’mizde bir de gösterge panelimiz bulunur. Bu gösterge panelinde devam eden tüm

Sprint’lere ulaşılabilir.

Ayrıca Scrum Master Sprint Bilgi formunun çıktısını alır ve takım odasının dışına bu sayfayı yapıştırır.

Böylece takım odasının yanından geçen biri bu sayfaya bakar ve takımın hangi işlerle ilgilendiğinden

haberdar olur. Takım odasının yanından geçen kişi, Sprint Bilgi Sayfası’nda, Günlük Scrum’ın, Sprint

demosunun yeri ve zamanı olduğu için daha fazlasını nerede ve ne zaman öğrenebileceğini bilir.

Sprint’in sonu yaklaştığında Scrum Master yapılacak demoyu herkese hatırlatır.

Bütün bunlar göz önüne alındığında, Takımın neler yaptığını bilmediği üzerine kimsenin şikayeti

olamaz ya da hatalı varsayımlarda bulunamaz.

Mükemmel fikir! Bunu daha sık yapmalıyım!

59

Bölüm

Altı

Sprint İş Listesi’ni Nasıl Oluştururuz?

Sprint Planlama Toplantısı’nı bitirdik ve yepyeni Sprint’imiz hakkında dünyaya bilgi verdik. Sıra Scrum

Master’ın Sprint İş Listesi’ni hazırlamasında. Bu aktivite Sprint Planlama Toplantısı’ndan sonra fakat

ilk Günlük Scrum’dan önce yapılmalıdır.

Sprint İş Listesi’nin Formatı

Sprint İş Listesi’nin farklı(Jira, Excel, fiziksel duvar) formatlarını deneyimledik. Başlangıçta Excel

kullandık, Sprint İş Listesi’ni oluşturabileceğiniz birçok farklı Excel şablonunu internette bulabilirsiniz.

Hatta otomatik burn-down grafik oluşturanlar bile var. Excel üzerindeki Sprint İş Listemizi nasıl

oluşturduğumuz üzerine çok şey söyleyebilirim. Fakat söylemeyeceğim. Hatta bir örnek bile

vermeyeceğim.

Bunun yerine bizce en etkili yol olan fiziksel duvardaki Sprint İş Listemizi detaylarıyla anlatacağım.

Kullanılmayan bir duvar ya da üzerinde gereksiz şirket logosu, eski şablonlar ya da çirkin tablolar olan

büyük bir duvar bulun. Duvarı temizleyin(eğer gerçekten izin almanız gerekiyorsa izin alın).

Çoooooookkk büyük bir duvar kağıdı bulun en az 2x2 metre ya da 3x2 metre, daha sonra bunu yapın.

Fiziksel duvarlar(Scrum Duvarları) araçlar içinde her zaman ilk tercihimdir! Şaşırtıcı bir şekilde

güçlüdür. Takım üyeleri farklı lokasyonlarda bulunan takımlar Scrum Duvarı görüntüsüne sahip

bir araç kullanın, bunu sağlayabilen birçok uygulama mevcuttur. Daha sonra bu görüntüyü büyük

bir ekrana yansıtın. Günlük Scrum’da herkes ofisindeki ekranın karşısına geçebilir ve Skype(ya da benzeri bir araç) üzerinden konuşabilir.

60

Tabi ki beyaz tahta kullanabilirsiniz. Fakat bunu yapmak biraz israf gibi olabilir çünkü beyaz tahtaları

tasarım çizimleri için kullanmak daha doğrudur. Scrum Duvarı olarak kullandığınızda atıl kalmış

olacaktır.

Eğer işler(task) için yapışkan kağıt kullanıyorsanız gerçek bant kullanarak yapıştırmayı unutmayın.

Yoksa bir gün geldiğinizde yapışkan kağıtlardan oluşan bir zeminle karşılaşabilirsiniz.

Daha güzeli! Süper yapışkan kağıtlar kullanın. Biraz daha pahalılar fakat düşmüyorlar.(Hayır,

düşündüğünüz gibi değil bana sponsor olmadılar.)

Daha güzeli! Duvarlarınızın tamamını beyaz tahtayla kaplatın! Buna değecek bir yatırım.

61

Scrum Duvarı Nasıl Kullanılır?

Elbet istediğiniz kadar kolon ekleyebilirsiniz. “Entegrasyon testi için bekleyenler” ya da “İptal

edilenler”. Bir şeyleri karışık hale getirmeden önce iyi düşünün. Ekleyeceğiniz bu kolon gerçekten

ama gerçekten gerekli mi?

Bu konularda basitliğin hayati derecede önemli olduğunu düşünüyorum. Bu nedenle işi

karmaşıklaştıracak şeyleri yapmamanın bedeli gerçekten çok yüksekse yapıyorum.

Örnek 1: İlk Günlük Scrum’dan sonra

İlk Günlük Scrum’dan sonra Scrum Duvarı aşağıdaki gibi görünebilir:

62

Gördüğünüz gibi sadece üç iş ileriki bir kolona taşındı. Geliştirme Takımı bugün bu işler üzerinde

çalışacak demektir.

Bazen büyük takımlarda bir iş “check out” kolonunda kalabiliyor çünkü hiç kimse o işle ilgili kimin

çalıştığını hatırlamıyor. Eğer bu olay bir takımda sık oluyorsa bunun için bir kural belirlenir örneğin bir

işi “check out” kolonuna taşıyan kişinin adını yapışkan kağıdın üzerine yazabiliriz.

Bugünlerde herkes avatar kullanıyor. Geliştirme Takımı’nın her bir üyesi kendine bir karakter(South

Park karakteri ya da herhangi bir şey) seçer, çıktısını alır ve bir mıknatısla bunu duvara yerleştirir.

Kimin hangi iş üzerinde çalıştığını görmenin harika bir yoludur. Ayrıca Geliştirme Takımı üyelerinin

sadece iki tane mıknatısı olduğunu varsayalım, o zaman hem aynı anda çalışılan iş sayısını limitlemiş

hem de çok görevliliğin önüne geçmiş olursunuz. “WTF(İngilizce’deki güzel olan birkaç ifadeden biri),

yapıştıracak avatarım kalmamış!” Evet, işte bu nedenle yeni işlere başlamayı bırak ve elindeki işleri

bitirmeye başla!

63

Örnek 2: Birkaç gün sonra

Birkaç gün sonra Scrum Duvarı aşağıdaki gibi görünebilir:

Gördüğünüz gibi Deposit’le ilgili kullanıcı hikayesini tamamladık(kodlar kaynak kodla birleştirildi,

testleri ve kod iyileştirmeleri yapıldı). “Migration Tool” kullanıcı hikayesinin bir bölümü tamamlandı.

“Backoffice Login” kullanıcı hikayesine yeni başlandı ve “Backoffice User Admin” kullanıcı hikayesine

daha başlanmadı.

Sağ alt köşede gördüğünüz gibi planlamaya dahil etmediğimiz üç maddemiz bulunuyor. Sprint

Retrospektif Toplantısı’nda bunları konuşmak isterseniz diye hatırlatıcı olarak bulunması kullanışlı

olabilir.

Aşağıda Sprint sonuna yaklaşmış gerçek bir Scrum Duvarı’nın resmi bulunuyor. Sprint ilerledikçe

duvar karmaşık hale gelir. Scrum Duvarı her Sprint’te yeniden oluşturulduğu için karmaşık hale

gelmesinde herhangi bir problem yok.

64

Burn-down Grafik Nasıl Oluşturulur?

Burn-down grafiğe yakından bakalım!

Bu grafikten aşağıdaki bilgilere ulaşabilirsiniz:

● Sprint’in ilk günü 1 Ağustos’ta Geliştirme Takımı 70 hikaye puanlık kalan iş olduğunu tahmin

etmiştir. Aslında bu takımın tahmin edilen hızıdır.

● 16 Ağustos’ta Geliştirme Takımı 15 hikaye puanlık kalan iş olduğunu tahmin etmiştir. Kesikli

çizgi yaklaşık olarak iyi bir seviyede olduklarını gösterir. Eğer bu hızla ilerlemeye devam

ederlerse Sprint sonunda bütün işleri tamamlamış olacaklardır.

65

X ekseni üzerinde tatil günlerini atlarız. Sonuçta hafta sonları neredeyse iş yapılmıyor. Önceleri hafta

sonlarını da dahil ederdik fakat bu burn-down grafiğin biraz karmaşık olmasına neden oluyor. X

ekseni üzerinde hafta sonuna denk gelen bölümler düz bir çizgi olarak kalıyordu. Bu da grafiğimizin

uyarı işareti gibi görünmesine neden oluyordu.

Scrum Duvarı’nda Uyarı İşaretleri

Scrum Duvarı’na hızlı bir bakış atan herkes Sprint’in nasıl ilerlediğine dair fikir sahibi olabilmeli.

Scrum Master, Takımın uyarı işaretlerini dikkate alarak hareket etmesinden sorumludur. Uyarı

işaretleri aşağıdakiler gibi olabilir:

Scrum bir aylık Sprint’ler koşan takımlar için tasarlanmıştır ve işlerin takibi için Excel

kullanılmıştır. Böyle bir durumda burn-down grafik gerçekten çok kullanışlı bir araçtır. Nerede

olduğunuzu görsel bir şekilde çok güzel gösterir. Şimdilerdeyse birçok takım daha kısa Sprint’ler

koşmaktadır ve oldukça görsel Scrum Duvarları bulunmaktadır. Bu nedenle bazı takımlar burn-

down grafik çizmeyi bırakmıştır. Çünkü Scrum Duvarı’na bir bakışla ihtiyaç duydukları bilgiyi

edinebilmektedirler. Burn-down grafiği kullanmayın bakalım özleyecek misiniz? :)

66

Takip Edilebilirlik?

Bu modelde takip edilebilirlik için önerebileceğim en iyi yöntem Scrum Duvarı’nın her gün bir

fotoğrafının çekilmesidir. Ben de bu yöntemi kimi zaman denerim fakat fotoğrafları incelemek gibi bir

ihtiyacım hiç olmadı.

67

Eğer takip edilebilirlik sizin için çok önemliyse belki de Scrum Duvarı çözümü sizin için uygun değildir.

Fakat size şunu önerebilirim: Sprint’in detaylı bir planlamasını yapabilirsiniz. Sprint bittiğinde ve

çalışan kod teslim edildiğinde, gerekli dokümanlar oluşturulduğunda Sprint’in beşinci gününde kaç

kullanıcı hikayesinin tamamlandığını biri önemsiyor mu? Deposit kullanıcı hikayesi için test

yazılmasının kaç saat sürdüğü ve bu testin yazılması için kaç saat tahminde bulunulduğunu biri

önemsiyor mu?

Bugünlerde de takip edilebilirliğin çok abartıldığını düşünüyorum. Bu tarz verileri sağlayan araçlar

bulunuyor fakat kullanan birini hiç görmedim. Kod versiyon kontrol sisteminiz ihtiyacınız olan şeyi

fazlasıyla verecektir. (WTF, bu değişikliği kim yaptı?) Basit kurallar koyabilirsiniz örneğin kullanıcı

hikayesinin numarasını kodunuzu göndermeden önce yorum bölümüne ekleyebilirsiniz ve birçok

durum için takip edilebilirlik elde edebilirsiniz.

Tahminler Günlük mü, Saatlik mi Olmalı?

Scrum üzerine yazılan kitaplar ve makalelerde işler(task’lar) saat bazında tahmin edilmiştir, gün

bazında değil. Bizde saatleri kullanıyorduk. Genel formülümüz: 1 verimli adam/gün = 6 verimli

adam/saat.

Aşağıdaki nedenlerden dolayı bugünlerde bu yöntemi birçok takımımızda kullanmıyoruz:

- Adam/Saat tahminler işleri çok küçük parçalara bölmek anlamına geliyor. Bu da bir saatlik, iki

saatlik birçok iş olmasına ve dolaylı olarak mikro yönetime kayıyor.

- Zamanla anladık ki tahminler yapılırken zaten herkes adam/gün olarak düşünüyormuş ve

adam/saat tahminleri yaparken 6 ile çarpıyormuş. “Hmmm bu iş 1 günde biter o zaman bu

işe 6 saat yazabiliriz.

- İki farklı birim kafa karışıklığına neden olur. “Bu tahminler adam/gün mü yoksa adam/saat

mi?

Bu nedenle tüm zaman bazlı tahminler için adam/gün’ü kullanırız. Bu tahminlere hikaye puanı deriz.

En küçük değerimiz 0.5’tir. 0.5’ten daha küçük işler ya silinir ya da diğer birkaç küçük işle bir araya

toplanır. En kötü ihtimalle 0.5’ten küçük olsa bile 0.5 olarak değer veririz. Tahminlerde küçük

sapmalar takıma büyük zarar vermez. Güzel ve basit olmak daha önemlidir.

68

Daha basit ve güzeli: İşlerin büyüklüğüne tahmin vermeyi tamamen bırakın! Birçok takım işlerini

bir ya da iki günlük küçük işlere nasıl böleceğini zamanla öğrenir. Eğer bunu yapabilirseniz işlere

büyüklük tahmini vermeye zahmet etmeyin. Aslında böylece oldukça büyük bir çöpü* ortadan

kaldırmış olursunuz. Eğer kullanmak istiyorsanız burn-down grafikleri yine de kullanabilirsiniz. Bu

durumda sadece işleri(task’ları) saymanız ve burn-down grafikte nerede olduğunuzu belirlemeniz

yeterli olacaktır.

*Alper Tonga'nın Kanban; Evrimsel Değişim – S01E01 yazısını okuduktan israf sözcüğünün yerine

çöp sözcüğünü kullanmaya başladım. Alper'in çöp sözcüğünü kullanmasının nedeni çöpün somut

olarak bir varlık ifade etmesidir. Çöp, kötü kokusu, çirkin görüntüsü olan ve kurtulmamız gereken

her şey olabilir. Bu tanımın yanında israf sözcüğü kulağa çok soyut geliyor. Bu soyut anlam

aksiyon almamız için uyarıcı bir nitelik taşımıyor. Çöp ifadesini topluluğa kazandırdığı için Alper

Tonga'ya teşekkür ederim.

69

Bölüm

Yedi

Takım Odasını Ayarlama

İlginç ve değerli tasarım konuşmalarının birçoğunun Scrum Duvarı önünde gerçekleştiğini fark ettim.

Bu nedenle bu bölümü “tasarım köşesi” olarak belirledik.

Çok yararlı olduğunu gördük. Tüm sistemin nasıl çal ıştığını anlayabilmek için tasarım köşesinde iki

Scrum Duvarı’na ve gerektiğinde bilgisayara bakmaktan daha iyi bir yol bulamadık.

“Tasarım duvarı”, en önemli tasarım çizimlerinin ve en önemli tasarım dokümanlarının(ara yüz

prototipleri, domain modelleri) çıktılarının bulunduğu bir beyaz tahtadır.

70

Yukarıdaki resimde biraz evvel bahsettiğim köşede bir Günlük Scrum yapılıyor.

Hmm…burn-down grafik şüpheli bir şekilde dümdüz inmiş, değil mi? Fakat Takım bunun gerçek

olduğunda ısrar ediyor. ☺

Takım Beraber Otursun!

Konu takım üyelerinin nerede oturacağına ve masalarının nerede olacağına geldiğinde yeterince

güçlü ifade edilmeyen bir şey var.

Takım beraber otursun!

Daha net olması için tekrar söylüyorum:

Takım beraber otursun!

İnsanlar yerlerini değiştirmeye direnç gösterirler. En azından benim çalıştığım yerlerde. Bütün

eşyalarını ve bilgisayarını toplayıp başka bir masaya taşınmak istemezler. Taşınacakları mesafe ne

kadar az olursa direnç o kadar yüksek olur. “Hadi aaaammmaaa! Oradan oraya beş metre taşınmanın

anlamı nedir ki?”

Scrum konusunda şirketlere 8 yıldır yardım ediyorum ve eklemek istediğim bir şey var:

TAKIM BERABER OTURSUN!

71

Verimli Scrum Takımları oluştururken başka bir alternatif yoktur. Takım üyelerini bir araya getirin.

Her bir takım üyesini tehdit etmek, tüm eşyalarını taşımak ve eski kahve izlerini silmek zorunda

olsanız bile. Eğer takımın beraber oturabileceği bir yer yoksa oturabilecekleri bir yer ayarlayın. Hatta

gerekiyorsa bodrum kata taşının. Masaları sağa sola çekin, ofis yöneticisine rüşvet verin, ne

gerekiyorsa yapın. Takım beraber otursun.

Bir kere takım beraber oturmaya başladığında anında kazanç elde etmeye başlayacaksınız. Bir

Sprint’ten sonra Takım bunun iyi bir fikir olduğunda fikir birliğine varacaktır.

Peki “beraber” ne anlama geliyor? Masalar nasıl yerleştirilmeli? Masaların en iyi şekilde nasıl

yerleştirilebileceğine dair bir fikrim yok. Fakat olsa bile birçok takımın nasıl oturabileceklerini

belirleme lüksüne sahip olmadığını varsayıyorum. Genellikle fiziksel kısıtlar vardır, komşu takım,

tuvalet kapısı ya da ofisin ortasındaki otomat.

Beraber’in anlamı:

Duyulabilirlik: Takımdaki herhangi biri başka biriyle konuşmak için bağırmamalı ya da masasından

kalkmamalıdır.

Görülebilirlik: Herkes birbirini görebilmelidir. Herkes Scrum Duvarı’nı görebilmelidir. Okuyacak kadar

yakın olmak şart değil fakat görebilecek kadar yakın olunmalıdır.

İzolasyon: Eğer takım üyelerinizin tamamı birden ayağa kalkıp bir konu hakkında konuşmaya

başlarsa, bir tasarım konusunda canlı bir tartışma yaşanırsa takım dışındaki kişilerin rahatsız

olmayacağı kadar ayrı olunmalıdır. Tabi ki tersi de geçerlidir, takım üyeleri diğer çalışanları rahatsız

etmeyecek şekilde olması gerekir.

“İzolasyon”un anlamı takımın organizasyondan tamamıyla yalıtılması demek değildir. Kübiklerden

oluşan bir ofiste takımınızın kendi kübiğinin bulunması ve rahatsız edici seslerden yalıtılmış olması

yeterli olabilir.

72

Peki ya dağınık takımınız bulunuyorsa? O zaman şansınız yok demektir. Zararın en aza

indirgeyebileceğiniz kadar teknik yardımı(video konferans, web kameralar, masaüstü paylaşım

araçları vb.) kullanın.

Ürün Sahibi’ni Yakında Tutun

Ürün Sahibi, Geliştirme Takımı’nın bir sorusu olduğunda gidip sorabileceği ve Ürün Sahibi istediği

zaman gelip Scrum Duvarı’nı görebileceği kadar mesafede olmalıdır. Fakat Takımla beraber

oturmamalıdır. Neden? Çünkü büyük ihtimalle işlerin detayına karışmadan duramayacak ve Takım

kendi havasını(sıkı, kendini yöneten, hiper verimli bir hava) bulamayacak.

Doğruyu söylemek gerekirse bu bir spekülasyon. Ürün Sahibi’nin Takımla beraber oturduğu bir

durumla hiç karşılaşmadım. Bu nedenle bunun kötü bir fikir olduğuna dair elimde gerçek bir örnek

bulunmuyor. Sadece bir his ve diğer Scrum Master’lardan duyduklarım var.

Müdürleri ve Koçları Yakında Tutun

Hem müdür hem koç olduğum için bunu yazmak benim için biraz zor...

Takımla olabildiğince yakın çalışmak benim işimdi. Takımları kurardım, birinden diğerine yardıma

koşardım, takım üyesi arkadaşlarımla eşli programlama yapardım, Scrum Master’lara koçluk

yapardım, Sprint Planlama Toplantıları’nı ayarlardım. Birçok kişi bunun iyi bir şey olduğunu

düşünüyordu çünkü Çevik yazılım geliştirme üzerine bilgim vardı.

Fakat aynı zamanda yazılım geliştirmeden sorumlu müdürdüm. Bunun anlamı bir takımla bir araya

geldiğimde otomatik olarak takımın kendi kendini yönetmesine olumsuz etki ediyordum. Bu

olumsuzluğun oluşması benim yaptıklarımdan değil sadece varlığımdan kaynaklanıyordu. “Offf

patron geldi. Muhtemelen ne yapmamız gerektiğine ve kimin yapması gerektiğine dair birçok fikri

vardır. En iyisi konuşma işini ona bırakalım.”

Çok büyük yanılmışım hem de çok büyük. Gördüğüm en iyi takımlar içinde Ürün Sahibi bulunan

takımlardır. Ürün Sahibi uzakta ve erişilemez olduğunda Geliştirme Takımları büyük sıkıntı

yaşarlar. Bu da yakın olmaktan kaynaklanan problemlerden daha büyüklerine neden olabilir. Ürün

Sahibi, Takım ve paydaşlarla geçirdiği zamanı ölçülü bir şekilde dengelemelidir. Demek istediğim

şey zamanının tamamını Geliştirme Takımı’yla geçirmemelidir.

73

Benim mottom: Eğer Scrum Koçu’ysanız(belki aynı zamanda yönetici) olabildiğince takıma dahil olun.

Fakat sadece belirli bir zaman dilimi için daha sonra kenara çekilin ve takımın kendi kendini

yönetmesine izin verin. Arada bir takımı kontrol edin, bu çok sık olmasın. Belki Sprint demolarına

katılabilirsiniz ya da Scrum Duvarları’na göz atabilirsiniz, Günlük Scrum’larına katılıp dinleyebilirsiniz.

Eğer bir geliştirme alanı görürseniz Scrum Master’ı kenara çekin ve koçluk yapın, bunu takım önünde

yapmayın. Diğer iyi bir fikirse Sprint Retrospektif Toplantısı’na katılmak olabilir. Eğer takımınız size

yeterince güveniyorsa sizin varlığınızdan ötürü içlerine kapanmayacaklardır.

İyi işleyen bir Scrum Takımı için takımınızın ihtiyacı olan her şeyi yaptığınızdan emin olun ve daha

sonra takımın önünden çekilin ta ki Sprint demosuna kadar.

Çeviklik bağlamında müdürlere verebileceğim en iyi tavsiye son cümledir. İyi müdürler, takımın

başarısında çok önemli etkendir. İyi bir müdür olarak takımın size ihtiyacı kalmayacak şekilde

takımı yetiştirmeli ve geri çekilmelisiniz. Muhtemelen bunda başarısız olacaksınız fakat deneme

girişiminiz bile sizi doğru yöne itecektir. “Bu takımı nasıl yönetmeliyim?” sorusundan ziyade

“Takımın kendini yönetmesi için neye ihtiyacı var?” sorusunu sorun. Takımın ihtiyacı olan

şeffaflık, net bir hedef, eğlenceli ve motive edici bir iş ortamı ve engelleri çözebilmek için

yönetimsel olarak izlemeleri gereken bir yol.

74

Bölüm

Sekiz

Günlük Scrum’ları Nasıl Yapıyoruz?

Günlük Scrum’larımız oldukça kitabına uygun şekilde gerçekleşiyor. Her gün aynı yer ve saatte

zamanında başlıyor. Başlangıçta Sprint planlamasını* yapmak için başka bir odaya gidiyorduk(o

günlerde elektronik bir Sprint İş Listemiz vardı). Her neyse bugünlerde Günlük Scrum’ı Scrum

Duvarı’nın önünde yapıyoruz ve hiçbir teknik bundan daha iyi değil.

Günlük Scrum Toplantıları’nı ayakta yapıyoruz çünkü ayakta yapmamız 15 dakika zaman kısıtını

aşmamız riskini azaltıyor.

*Yazar Sprint Planlama Toplantısı’ndan bahsetmiyor. Her gün takım üyelerinin bir araya gelip Günlük Scrum

Toplantısı’nda Sprint’te nasıl i lerlemeleri gerektiğini konuşurlar. Bu da Sprint’in yeniden planlanması anlamına

gelmektedir.

Scrum Kılavuzuna, son güncellemesinde(2006 güncellemesi olabilir) bu duruma karşılık üç soru

eklendi:

- Takımın, Sprint Hedefine ulaşabilmesi için ne yaptım?

- Takımın, Sprint Hedefine ulaşabilmesi için bugün ne yapacağım?

- Benim ya da Takımı’mın önünde engel var mı?

Günlük Scrum gerçekten çok önemlidir! Bilgi senkronizasyonunun çoğunun gerçekleştiği ve

Takımın önündeki engellerden bahsettiği yerdir. Yine de kötü yapılıyorsa oldukça sıkıcı olabilir. Bir

grup insan düzensiz bir şekilde konuşuyor ve kimse kimseyi dinlemiyor.

75

Scrum Duvarı’nı Güncelleme

Normalde Scrum Duvarı’nı Günlük Scrum Toplantıları’nda güncelleriz. Her bir takım üyesi dün ne

yaptım, bugün ne yapacağım konularını özetlerken Scrum Duvarı’ndaki yapışkan kağıtları da

günceller. Planlanmayan bir iş geldiyse bunun için yeni yapışkan kağıtlar yazılır ve duvara yapıştırılır

ya da ilerleme kaydedilen bir işte zaman güncellenir. Bu bazen iş için ayrılan zamanın azaltılması ya

da artırılması olabilir.

Bazı takımların Günlük Scrum öncesinde Scrum Duvarı’nın güncellenmesi gibi kuralları vardır. Bu da

işe yarayan bir yöntemdir. Önemli olan kuralı belirlemektir ve bu kurala uymaktır.

Sprint İş Listenizin hangi formatta olduğuna bakmadan bütün takımın Sprint İş Listesi’ni güncel

tutmasını sağlayın. Scrum Master’ın Sprint İş Listesi’nden sorumlu tek kişi olduğu Sprint’ler yaptık.

Scrum Master, her gün takım üyelerine gidip işlerin tamamlanması için ne kadar zaman kaldığını

öğrenmek zorundaydı. Bu yöntemin dezavantajları aşağıdaki gibi:

● Scrum Master, yönetimsel işlere çok fazla zaman harcıyor. Halbuki bunun yerine takıma

destek olabilir ve engelleri ortadan kaldırabilir.

● Takım üyeleri Sprint’te hakkındaki farkındalıkları azalıyor. Sonuçta Sprint İş Listesi bu

yöntemde onların önemsediği bir şey olmuyor. Bu geri bildirim eksikliği takımın çevikliğinin

ve odağının azalmasına neden oluyor.

Sprint Hedefine(takımın paylaşılmış amacı) odaklanıldığının farkına vardınız mı? Eğer Günlük

Scrum’larınız sıkıcı olmaya başladıysa yukarıdaki soruları deneyebilirsiniz! Ya da Dan North

versiyonunu deneyebilirsiniz: “Bugünün spesiyali nedir?” cümlesiyle açık bir tartışma

başlatılabilir. Ne yaparsanız yapın Günlük Scrum’ların sıkıcı olmasına izin vermeyin. Deney

yapmaya devam edin.

Birçok takım Günlük Scrum Toplantısı’nda işleri güncellemeye aşırı zaman harcar. Çöp! Günlük

Scrum’ın amacı takım üyeleri arasındaki bilginin eşitlenmesidir. Bu nedenle bence duvarın

güncellenmesi için en iyi yol “gerçek zamanlı” yapmaktır. Yani gün içinde olaylar geliştikçe duvarın

güncellenmesidir ve işlerin(task’ların) tahminlenmesi işi tamamıyla bırakılmalıdır. Böylece Günlük

Scrum, yönetimsel işler yerine gerçekten iletişim kurabilmek için kullanılır.

76

Eğer Sprint İş Listesi iyi tasarlanmışsa her bir takım üyesi kolayca güncellemelerini yapabilir.

Günlük Scrum Toplantısı’ndan hemen sonra takımdan biri bütün zaman tahminlerini toplar ve Sprint

burn-down grafiğini çizer.

Geç Gelenlerle Başa Çıkma

Bazı takımlar bozuklukların ve kağıt paraların olduğu kutuları vardır. Geç kaldığınız zaman bir dakika

bile olsa kutuya katkıda bulunursunuz. Bunun bahanesi yoktur. Eğer toplantıdan önce arar ve geç

kalacağınızı söyleseniz bile kutuya katkıda bulunmak zorundasınız. Eğer gerçekten sağlam bir

bahaneniz varsa katkıda bulunmayabilirsiniz örneğin doktor randevusu ya da düğününüz falan…

Kutudaki para sosyal etkinlikler için kullanılabilir. Oyun gecelerinde hamburger almak için mesela. :)

Bu yöntem başarılıdır. Fakat sadece geç kalanların çok olduğu takımlar için gereklidir. Bazı

takımlarınsa buna ihtiyacı yoktur.

“Bugün Ne Yapacağımı Bilmiyorum”cularla Başa Çıkma

“Dün şunları, şunları, şunları yaptım. Bugün ne yapacağıma dair aklımda hiçbir şey yok!” ifadesi

yaygın bir şekilde kullanılır. Eeee şimdi ne olacak?

Diyelim ki Lisa ve Joe ne yapacaklarını bilmeyen kişiler olsun.

Eğer ben Scrum Master’sam Lisa ve Joe’u geçer sıradaki kişinin konuşmasını isterim fakat Lisa ve

Joe’un yapacak işleri olmadığına dair notumu da alırım. Herkes konuştuktan sonra Takımla beraber

Scrum Duvarı’na yaklaşır ve yukarıdan aşağıya her şey olması gerektiği gibi mi bakarım. İşi olmayanlar

için yeni işler belirlenir ve daha sonra ne yapacağını bilmeyen kişilerin yanına gider, yeni işlerin

eklendiğini söylerim. Ne yapacaklarına dair fikirleri olup olmadığını sorarım ve sonunda bir fikir

edinirler.

Takımlar iyileştirmeler için bu tarz şaka yollu aktiviteleri her zaman kullanırlar. Önemli olan

bunun takım içinden çıkmasıdır. Bu şaka yollu iyileştirme takıma yukarıdan ya da dışarıdan zorla

gelmemelidir. Bir takımda geç kalan kişiler şarkı söylemek zorundaydılar. Eğer ikinci defa geç

kalırsanız hem şarkı söylemek hem de dans etmek zorundaydınız. :)

77

Eğer yine de fikirleri yoksa eşli programlama için birileri var mı bakarım. Diyelim ki Niklas arka ofis

yönetici ekranını geliştirecek. Bu durumda nazik bir şekilde Lisa ya da Joe’un Niklas ile eş olmasını

rica ederim. Genellikle çalışan bir yöntemdir.

Eğer bu yöntemde işe yaramıyorsa işte küçük bir numara:

Scrum Master: Betaya hazır teslim sürümünü kim göstermek ister?(Diyelim Sprint Hedefi bu olsun)

Team: (Takımın kafası karışır ve sessizce bekler)

Scrum Master: Daha bitiremedik mi?

Team: hmmm...hayır.

Scrum Master: Hadi ya! Neden ki? Ne kaldı?

Team: Test makinemiz yok, derleme script’lerinin düzeltilmesi gerekiyor.

Scrum Master:(Scrum Master içinden Aha! der) Hadi ya, Scrum Duvarı’na iki yapışkan kağıt daha

ekler. Joe, Lisa, bugün bu konularda yardımcı olabilir misiniz?

Joe: Sanırım bir yerlerden bir test makinesi bulabilirim.

Lisa: O zaman bende derleme script’ini düzeltmeye çalışayım.

Eğer şanslıysanız sorduğunuz betaya hazır teslimi biri size gösterecektir. Harika! Sprint Hedefi’ne

ulaştınız. Fakat ya Sprint’in ortasındaysanız ne olacak? Takımı iyi iş çıkardıkları konusunda tebrik edin.

Ürün İş Listesi’nden alınması gereken işleri belirleyin. Bunları Sprint İş Listesi’ne ve Scrum Duvarı’na

ekleyin. Yeni bir Günlük Scrum yapın. Ürün Sahibi’ne Ürün İş Listesi’nden yeni işler çektiğinize dair

bilgi verin.

Diyelim ki Takım, Sprint Hedefi’ne ulaşmadı ve Joe ve Lisa Sprint Hedefi’ne yönelik bir şey yapmayı

reddediyorlar. Aşağıdaki stratejilerden birkaçını denerim(hiçbiri hoş değildir fakat son çaredir):

Utanma:”Peki, takıma nasıl yardımcı olabileceğinize dair fikriniz yoksa eve gitmenizi ya da kitap

okumanızı falan öneririm. Ya da oturun ve biri sizi yardım için çağırana kadar bekleyin.”

Eski Usül: En basit haliyle iş atayın.

Ya da bu zamanı teknik borcu ödemek ya da yeni teknolojileri keşfetmek için kullanabilirsiniz.

Yine de Ürün Sahibi’ni bilgilendirin.

78

İş Arkadaşı Baskısı:”Joe ve Lisa Sprint Hedefi’ne ulaşabilmemiz için yapacak yararlı bir şey bulana

kadar burada bekleyeceğiz. O yüzden sakin olun ve bekleyin.”

Hizmetkarlık: “Peki Takıma direkt olmayan bir şekilde yapılması gerekenler konusunda hizmet

ederek yardımcı olabilirsiniz. Kahve alabilir, çalışanlara masaj yapabilir, çöpü temizleyebilir, öğle

yemeği yapabilir ya da gün içinde ne ihtiyacımız olursa onu yerine getirebilirsiniz.” Joe ve Lisa’nın

yapacakları teknik bir iş bulma hızına şaşıracaksınız.

Eğer bir kişi sık sık sizi bu kadar yoruyorsa muhtemelen o kişiyi bir köşeye çekmeli ve ciddi bir şekilde

koçluk yapmalısınız demektir. Eğer problem devam ederse bu kişinin takımınıza yararlı olup

olmadığını değerlendirmelisiniz.

Eğer çoookk önemli değilse takımdan gönderilmesini deneyebilirsiniz.

Eğer önemliyse ona çobanlık yapabilecek potansiyele sahip biriyle eşleştirebilirsiniz. Joe mükemmel

bir yazılım geliştirici ve mimar olabilir fakat bu kadar. Onun tercihi ne yapacağını başkalarının

söylemesi yönündedir. Niklas’a Joe’nun çobanı olma görevini verin ya da bu görevi siz üstlenin. Eğer

Joe takım için bu kadar önemliyse bu efora değecektir. Benzer durumlar yaşadık öyle ya da böyle işe

yaradı.

“Bugün ne yapacağımı bilmiyorum” durumu Scrum’a yeni başlayan takımlarda tipik bir

problemdir. Çünkü bu kişiler daha önceleri birilerinden emir alarak işlerini yapıyorlardı. Kendi

kendini yönetme konusunda tecrübe edindikçe problem ortadan kalkacaktır. İnsanlar ne

yapmaları gerektiğini öğreniyorlar. Yani Scrum Master’sanız ve yukarıdaki numaraları sık sık

kullanmak zorunda kalıyorsanız belki de bir adım geride durmayı düşünmelisiniz. Yardımsever

niyetinize rağmen belki de takımın önündeki en büyük engel, kendi kendini yönetmeyi

öğrenmelerinin önündeki engel siz olabilirsiniz.

79

Bölüm

Dokuz

Sprint Demo’larını Nasıl Yapıyoruz?

Sprint Demo(ya da Sprint Değerlendirme), Scrum’ın insanların küçümsemeye yatkın olduğu önemli

bir parçasıdır.

“Gerçekten demo yapmak zorunda mıyız? Gösterebileceğimiz çok fazla şey yok!”

“&%$# demoyu hazırlamaya vaktimiz yok!”

“Diğer takımların demo’larına katılmaya vaktim yok!”

Bütün Sprint’lerin Bir Demo’yla Bitmesinde Neden Israr Ediyoruz?

İyi yapılan bir demo’nun öyle görünmemesine rağmen etkisi büyük olur:

Takım başarısı için ödüllendirilir, kendilerini iyi hissederler.

- Takım dışındaki kişiler takımın neler yaptığından haberdar olur.

- Demo, paydaşlardan geri bildirim alınmasını sağlar.

- Demo’lar farklı takımların bir araya geldiği ve işleri üzerine konuştukları sosyal etkinlikler

olmalıdır. Bu çok değerlidir.

Neden Sprint Demo dediğimi hiç anlayamıyorum. Ne düşünüyordum acaba?! Resmi adı Sprint

Değerlendirme ve çok daha iyi bir terim. Demo tek yönlü bir iletişimi ifade ediyor. “İşte buyrun

bakın, bizim geliştirdiğimiz şey”. Öte yandan “Değerlendirme” çift yönlü bir iletişimi ifade eder.

“İşte buyrun bakın, bizim geliştirdiğimiz şey. Ne düşünüyorsunuz?” Sprint Değerlendirme’nin

amacı aslında müşteriden alınacak geri bildirimdir! Yani aşağıda demo diye bir şey okursanız

değerlendirme diye düşünün. Tamam mı?

80

- Demo yapmak, işleri bitirme ve teslim etme konusunda Geliştirme Takımı’nı motive eder,

dolaylı yoldan işleri bitirme konusunda yararlı bir strese neden olur. Demo’lar olmadan %99

bitmiş işleri üste üste yığıyoruz demektir. Demo’larla daha az iş bitiriyor olabiliriz fakat bu

işler %100 bitmiş oluyor. Bu durum tam bitmemiş bir sürü şeye sahip olmaktan daha iyidir.

Ayrıca bir sonraki Sprint’e bu yarım işlerde eklenecek ve bir sonraki Sprint’in odağını da

dağıtacaktır.

Eğer bir takım demo yapmaya zorlanırsa ve gösterecekleri gerçekten çalışan fazla bir şey yoksa demo

utanç verici geçecektir. Demo’yu yaparken takım kekeleyecek ve dili sürçecektir ve sonrasındaki

alkışlar çokta içten olmayacaktır. İnsanlar takım için kendilerini kötü hissedecektir. Belki de bazıları

bu kadar kötü bir demo yaptıkları için takıma kızacaktır.

Bu can yakar! Fakat etkisi acı bir ilacın etkisi gibidir. Bir sonraki Sprint takım bir şeyleri gerçekten

bitirmeye çalışacaktır. Şöyle düşüneceklerdir: “Belki de bu Sprint beş maddenin gösterimini yapmak

yerine iki maddenin gösterimini yapmalıyız. Fakat çalışan iki tane!” Takım ne yapmak zorunda

olduğunu bilir. Bu da bir sonraki demoda çalışan bir şeyler olma olasılığını artırır. Bunun olduğunu

birçok kere gördüm.

Birden fazla takımın çalıştığı projelerde bu durum daha da can sıkıcı bir şeydir. Projeye dahil olan

herkes düzenli aralıklarla yapılanların entegre olduğunu görmelidir. Entegrasyonla ilgili problemler

her zaman olacaktır. Fakat ne kadar erken fark ederseniz o kadar kolay çözebilirsiniz. Kendi kendini

yönetme sadece şeffaflık ve geribildirimlerle çalışır. İyi yapılan bir Sprint Değerlendirme ikisini de

sağlar.

Sprint Demo’lar için Kontrol Listesi

- Sprint Hedefi’ni net bir şekilde belirttiğinizden emin olun. Eğer ürününüz hakkında bilgi

sahibi olmayan insanlar varsa birkaç dakika ürününüzü anlatın.

- Demo’yu hazırlamak için çok fazla vakit harcamayın, özellikle janjanlı sunumlar. Boş işleri

konuşmayın ve yazılan kodun çalıştığını gösterin.

- Hızı yüksek tutun, demoyu güzel yapmaktansa hızlı yapmaya odaklanın.

- Demoyu iş(müşteri, işbirimi) odaklı tutun. Teknik detayları atlayın. Ne yaptığınıza odaklanın,

nasıl yaptığınıza değil.

- Eğer mümkünse katılımcıların ürünü kullanmasına izin verin.

81

- Bir sürü küçük ve önemsiz hata çözümünün gösterimini yapmayın. Onlardan bahsedin fakat

gösterimini yapmayın. Bu uzun zaman alacaktır ve daha önemli kullanıcı hikayelerinin odak

olmasını engelleyecektir.

Demosu Yapılamayacak İşler

Takım Üyesi: Bu maddenin sunumunu yapmayacağım. Çünkü demosu yapılamaz. Kullanıcı hikayesi:

“sistemin aynı anda 10.000 kullanıcıya hizmet vermesi için büyütülmesi”. 10.000 kullanıcıyı demoya

davet edip kullanıcı hikayesinin demosunu yapamam.

Scrum Master: Kullanıcı hikayesi bitti mi?

Takım Üyesi: Evet, tabiki.

Scrum Master: Emin misin?

Takım Üyesi: Sistemi performans testini yaptığımız ortama aldım, 8 yüklenici ana bilgisayarı

başlattım, aynı anda yapılan isteklerle sisteme yüklendim.

Scrum Master: Fakat sistemin aynı anda bağlı 10.000 kullanıcıyla başa çıkabileceğine dair gösterge

var mı?

Takım Üyesi: Evet. Test makineleri eski buna rağmen aynı anda 50.000 isteğe cevap verebildiler.

Scrum Master: Nerden biliyorsun?

Takım Üyesi: (Takım üyesi gerilmiş bir şekilde) Elimde raporu var! İstersen kendin görebilirsin. Testin

nasıl kurulduğunu ve kaç isteğin gönderildiği yazıyor.

Scrum Master: Süper! İşte senin demon. Sadece raporu göster, elinde hiçbir şey olmamasından

iyidir, değil mi?

Takım Üyesi: Sadece rapor yeterli mi? Fakat pek bir şeye benzemiyor, üzerinde biraz çalışmam ve

raporu parlatmam gerekiyor.

Scrum Master: Peki fakat çok fazla zaman harcama. Çok güzel olmasına gerek yok sadece bilgi verici

olsun yeter.

Bazı takımlar iki değerlendirme yaparlar: herkese açık küçük bir değerlendirme, takım dışı

paydaşların katılımının hedeflendiği bunu takiben daha detaylı, önemli zorlukların, teknik

kararların nasıl alındığının konusu olduğu bir değerlendirme yapılır. Takımlar arası bilgiyi yaymak

ve teknik detayları önemsemeyen paydaşları bundan ayrı tutmak için mükemmel bir yol.

82

Bölüm

On

Sprint Retrospektifleri Nasıl Yapıyoruz?

Neden Bütün Takımların Retrospektif Yapması Konusunda Israr

Ediyoruz?

Retrospektif konusunda en önemli şey yapıldıklarından emin olmaktır.

Bir nedenden ötürü takımlar retrospektif yapmak istemezler. Nazikçe bir dürtme olmasa

takımlarımızın birçoğu retrospektif toplantısını atlar ve gelecek Sprint’e başlarlardı. Belki İsveç’in

kültüründen kaynaklı bir şey, bilmiyorum.

Yine de retrospektiflerin yararlı olduğu konusunda herkes hemfikirdir. Aslında retrospektifin

Scrum’daki en önemli ikinci ritüel olduğunu söyleyebilirim. Birinci ritüel Sprint Planlama

Toplantısı’dır. Retrospektifse kendinizi geliştirmek için en iyi şansınızdır.

Hayır! Birçok ülkede aynı durumun yaşandığını gördüm. Yani bu insan doğasıyla ilgili bir şeydir.

Sürekli bir sonraki şeye geçmek istiyoruz. İronik bir şekilde ne kadar stres altındaysanız retrospektif

yapmama isteğiniz o kadar çok oluyor. Fakat ne kadar stresliyseniz aslında retrospektife o kadar

çok ihtiyacınız var demektir! Tıpkı şuna benziyor: “Ağaçları kesmek için o kadar acelem var ki durup

baltamı bileyecek vaktim yok!” Bu nedenle Scrum Master retrospektiflerin yapılması konusunda

gerçekten ısrarı olmalı. Çok fazla zaman harcamaya gerek yok. İki haftalık Sprint’ler için bir saatlik

Sprint Retrospektif Toplantısı yapılabilir. Fakat birkaç ayda bir yarım gün ya da tüm gün süren

retrospektifler yapın böylece daha çetrefilli konuları çözebilirsiniz.

Kesinlikle! Bu nedenle retrospektif Scrum’daki en önemli ritüel, ikinci değil!

83

Ortaya iyi fikirlerin çıkması için retrospektifi beklemenize gerek yok. Bunu küvetinizde de

yapabilirsiniz. Fakat takım fikrinizi kabul edecek mi? Belki, fakat takımın olurunu almak fikirler

takımdan çıkarsa çok daha olasıdır.

Retrospektif olmadan takımın aynı hataları tekrar tekrar yaptığını göreceksiniz.

Retrospektifleri Nasıl Organize Ederiz?

Genel format çeşitlidir. Fakat biz aşağıdakine benzer bir şey yapıyoruz:

- Ne kadar çok konuşulacağına bağlı olarak 1-3 saat arası zaman ayırırız.

- Katılımcılar: Ürün Sahibi, Geliştirme Takımı ve ben.

- Yakındaki bir odaya, rahat kanepelerin olduğu bir yer, verandaya ya da benzer bir yere

geçeriz. Yeter ki rahatsız edilmeden konuşabilelim.

- Retrospektifleri genellikle takım odasında yapmayız.

- Takımdan biri sekreter olarak belirlenir.

- Scrum Master, Sprint İş Listesi’ni gösterir ve Geliştirme Takımı’nın yardımıyla Sprint’i özetler.

Önemli olaylar ve kararların üstünden geçilir.

- Sprint içinde olanları “turlar” içinde konuşuruz. Scrum Takımı’nda bulunan herkes

bölünmeden konuşma şansı elde eder. İyi olduğunu düşündükleri şeyleri, daha iyi

olabileceğini düşündükleri şeyleri ve gelecek Sprint’te farklı yapmak istedikleri şeyleri

anlatırlar.

- Tahmin edilen ve gerçek takım hızını karşılaştırırız. Eğer arada çok büyük bir fark varsa neden

olduğuna dair bir analiz yaparız.

- Zamanın bitmesine yakın Scrum Master gelecek Sprint’te neleri daha iyi yapabileceğimize

dair somut önerileri özetlemeye çalışır.

Retrospektif toplantılarımızın çok katı bir yapısı yoktur. Gerçi ana tema her zaman aynıdır: “Gelecek

Sprint’te neyi daha iyi yapabiliriz?”

84

Son Sprint Retrospektif Toplantısı’ndan bir örnek:

Üç kolon:

- İyi: Eğer Sprint’i tekrar koşsaydık bu şeyleri aynı şekilde yapardık.

- Daha iyi olabilirdi: Eğer Sprint’i tekrar koşsaydık bu şeyleri farklı yapardık.

- İyileştirmeler: Gelecekte nasıl daha iyi olabileceğimize dair somut fikirler.

Yani birinci ve ikinci kolon geçmişe bakarken üçüncü kolon geleceğe bakar.

Yapışkan kağıtlardaki fikirler üzerine takım beyin fırtınası yaptıktan sonra “nokta oylamayla” gelecek

Sprint’te odaklanacağı iyileştirmenin hangisi olacağına karar verir. Her bir takım üyesine üç mıknatıs

verilir ve takımın gelecek Sprint’te odaklanması gerektiğini düşündükleri iyileştirmeleri seçmeleri

istenir. Herkes mıknatısları istedikleri iyileştirmeye yapıştırabilir. İsterlerse üç mıknatısı farklı

iyileştirme fikirlerine dağıtabilirler ya da üç mıknatısı da aynı iyileştirme üzerine yapıştırabilirler.

Takım beş iyileştirme noktası belirler ve bir sonraki retrospektifte bunları yerine getirip

getirmediğine bakar.

Burada aşırı hırslı olmamak önemlidir. Her Sprint için birkaç iyileştirmeye odaklanın.

Retrospektif yapmanın birçok eğlenceli yolu vardır. Arada bir toplantı formatını değiştirin ki sıkıcı

olmasın. Agile Retrospectives kitabında birçok fikir bulacaksınız. Retromat, rastgele retrospektif

jeneratörüdür ve çok eğlencelidir. :) www.plans-for-retrospectives.com

Her neyse fark ettim ki yaptığım bütün tekniklerde yukarıdaki basit formata dönüyorum. Çoğu

zaman işe yarıyor. Daha basitini de yapabilirsiniz. 20 dakikalık bir kahve arası yapın ve iki konu

belirleyin: “Ne aynı kalmalı?”, “Neyi değiştirmeliyiz?”. Biraz sığ fakat bir şey yapmamaktan iyidir.

85

Takımlar Arası Bilgi Paylaşımı

Sprint Retrospektif sırasında ortaya çıkan bilgi genelde çok değerlidir. Satış müdürü takım üyelerini

satış toplantılarında teknoloji uzmanları olsun diye sürekli kaçırıyor bu nedenle takım odaklanma

sorunu mu yaşıyor? Bu önemli bir bilgidir. Belki diğer takımlar da benzer sorunlar yaşıyordur. Ürün

Yönetimini, ürünlerimiz hakkında daha fazla bilgilendirmeli miyiz? Böylece satış desteğini kendileri

verebilir.

Sprint Retrospektif bir takımın gelecek Sprint’te nasıl daha iyi iş yapabileceği üzerine değildir, bundan

daha büyük bir anlamı vardır.

Bununla ilgili stratejimiz çok basittir. Bir kişi(bu durum içinde ben) bütün retrospektiflere katılır ve

bilgi taşıyan köprü görevi görür.

Alternatifi her Scrum Takımı’nın retrospektif raporu yayınlamasıdır. Bunu denedik fakat birçok kişinin

bu tarz raporları okumadıklarını ve daha azının raporları dikkate alarak hareket ettiklerini anladık.

Rapor yayınlamanın yerine daha basit yolu seçtik.

Bilgi köprüsü görevi gören kişi için önemli kurallar:

- İyi bir dinleyici olmalıdır.

- Eğer retrospektifte kimse konuşmuyorsa basit fakat hedefi vuran, tartışmayı canlandıran

sorular sormak için iyi hazırlanmalıdır. Örneğin, “eğer zamanı geri alabilseydiniz ve bu Sprint’i

baştan yapabilseydiniz, neyi farklı yapardınız?”

- Bütün takımların retrospektiflerine katılmak için zaman ayırmalı ve gönüllü olmalı.

- Takımın ulaşamayacağı yerlere ulaşabilecek otoriteye sahip olmalı.

Bu yöntem oldukça iyi işliyor fakat belki daha iyi başka yaklaşımlar da vardır. Lütfen beni aydınlatın :)

Daha iyisi satış müdürüyle bir toplantı yapın, ihtiyaçlarını öğrenin ve olası çözümleri beraber

konuşun!

Toplantıları yöneten kişilerin arada çapraz olarak değişmesi iyi bir modeldir. “Senin takımın

retrospektifini ben yapacağım, sen de benim takımın retrospektifini yaparsın.” İki yönlü bilgi

paylaşımı yapmanın kolay yoludur. Ayrıca Scrum Master olarak takımınızın retrospektifine

tamamıyla katılım gösterebilirsiniz çünkü retrospektifi yönetmekle uğraşmamış olacaksınız.

86

Değişmeli ya da Değişmemeli

Diyelim ki takım üyeleri takım içinde iletişimin çok az olduğunu, sürekli olarak yaptıkları işlerin

çakıştıklarını ve birbirlerinin tasarımlarını etkilediklerini söylüyorlar.

Ne yapmalısınız? Günlük tasarım toplantıları? İletişimi basitleştirici araçlar önerme? Wiki’ye daha

fazla bilgi koyma? Belki evet, belki de hayır.

Birçok durumda şunu anladık ki bir problemi net bir şekilde tanımlamak, problemin gelecek Sprint’te

kendi kendine çözülmesini sağlar. Özellikle Sprint Retrospektif’ini takım odasına asarsanız. Yaptığınız

her değişikliğin bir maliyeti vardır. Bu nedenle değişikliği yapmadan önce hiçbir şey yapmamayı göz

önünde bulundurun ve problemin kendiliğinden çözülmesi ya da küçülmesini umut edin.

Yukarıdaki iletişim örneği belki de hiçbir şey yapmadan kendiliğinden çözülecek problemlere en iyi

örnektir.

Biri bir konuda şikayette bulunduğu zaman şikayetin hemen ertesinde bir değişiklik yapmak

insanların küçük problemleri gizlemesine neden olur. Bu takımı olumsuz etkileyen bir şeydir.

Retrospektifte Ortaya Çıkan Örnekler

Aşağıda Sprint Retrospektif Toplantısı’nda ortaya çıkan tipik örnek bulunuyor.

“Kullanıcı hikayelerini daha küçük kullanıcı hikayelerine ya da işlere

bölmek için daha fazla zaman ayırmalıyız”

Bu oldukça yaygındır. Her Günlük Scrum’da takım üyeleri kendilerini “bugün ne yapacağımı

gerçekten bilmiyorum” derken bulur. Bu nedenle her Günlük Scrum’dan sonra somut işleri ortaya

çıkarmak için zaman harcarsınız. Bunu öncesinde yapmak daha verimli olacaktır.

Aksiyon: Yok. Büyük ihtimalle Takım gelecek Sprint Planlama’da bunu kendisi çözecektir. Eğer bu

durum devam ederse Sprint Planlama için ayrılan süreyi artırın.

87

“Dikkat dağıtan şeyler”

Aksiyonlar:

- Takımın Gelecek Sprint’te odak çarpanını azaltmasını söyleyebilirsiniz. Böylece daha gerçekçi

bir planları olabilir.

- Dikkati dağıtan şeyleri kaydetmelerini isteyebilirsiniz. Kim dikkatlerini dağıttı, ne kadar sürdü

vb. Bunları kaydetmek problemin çözümüne faydalı olacak mı?

- Dikkat dağıtan konularda Scrum Master’a ya da Ürün Sahibi’ne yönlendirme yapılmasını

söyleyebilirsiniz.

- Bir kişinin nöbetçi olarak belirlenmesini söyleyebilirsiniz. Dikkat dağıtan her şeyi nöbetçi

göğüsleyecek böylece geriye kalan takım üyeleri gerçekten işlerine odaklanabilecekler. Bu

kişi Scrum Master olabilir mi yoksa dönüşümlü olarak mı yapılmalı?

“Sprint’e fazla iş alıyoruz ve aldıklarımızın yarısını bitirebiliyoruz”

Aksiyon: Yok. Muhtemelen Takım, Gelecek Sprint’te yapabileceğinden fazla iş almayacak, en azından

bu Sprint’te olduğu kadar çok almayacak.

“Ofisimiz çok gürültülü ve dağınık”

Aksiyon:

- Daha iyi bir ofis ortamı oluşturmaya çalışın ya da takımı başka bir yere taşıyın, otel odası

kiralayın.

Dönüşümlü nöbetçi modeli oldukça yaygın ve genelde iyi işliyor. Deneyin!

2014 yılı itibariyle “Sprint Commitment” ifadesi Scrum Kılavuzu’ndan tamamıyla kaldırıldı. Bunun

yerine “Sprint Tahmini” ifadesi geldi. Commitment ifadesi çok fazla yanlış anlaşılmaya neden

oluyordu. Birçok takım Sprint planının bir çeşit söz verme olduğunu düşünüyordu(Çeviklik’teki

dört ana değerden birinin “plana uymaktan ziyade değişime cevap verme” olduğu göz önünden

bulundurulunca, biraz uyumsuz bir ifadeydi commitment). Sprint planı bir söz verme değildir

sadece bir tahmin ve hipotezdir. “Sprint Hedefi’ne ulaşabileceğimizi düşündüğümüz en iyi yol

budur!”

Yine de tahmin ettiğinden daha azını teslim etmek kötü bir durum. Eğer problem buysa bir önceki

Sprint’te bitirebildiğiniz kadar işi Sprint’inize alma konusunda katı davranın. Bu basit ve güçlü bir

numaradır ve genellikle problemlerin ortadan kalkmasını sağlar.

88

- Eğer bunlar olası değilse takıma odak çarpanını düşürmelerini söyleyin. Daha sonra yönetime

odak çarpanının düşürülmesinin nedeninin ofisin gürültülü ve dağınık olmasından

kaynaklandığını söyleyin. Bu Ürün Sahibi’nin üst yönetime baskı yapmaya başlamasına neden

olacaktır.

Ne mutlu ki bana takımı bir otel odasına taşıma gibi bir tehditte bulunmadım. Fakat zorunda kalırsam

yaparım. :)

89

Bölüm

Onbir

Sprint’ler arasında boş zaman

Gerçek hayatta sürekli Sprint’ler atamazsınız. Sprint’ler arasında dinlenmeniz gerekir. Eğer sürekli

Sprint koşuyorsanız gerçekte sadece koşuyorsunuzdur.

Genel kural Scrum ve yazılım geliştirme için de geçerlidir. Sprint’ler oldukça yoğun olabilir. Yazılım

geliştirici olarak boş zamanınız hiç olmayabilir. Her gün Günlük Scrum’a katılıp dün ne yaptığınızı

insanlara söylemek zorundasınız. Çok az kişi zamanımın çoğunda bacaklarımı masaya uzattım ve

blog’ları arasında dolaştım, kahvemi yudumladım diyebilir.

Ayrıca Sprint’ler arasında boş zamana sahip olmak için başka iyi bir neden daha vardır. Sprint

demo’sundan ve Sprint Retrospektif Toplantısı’ndan sonra Takım ve Ürün Sahibi sindirmeleri gereken

birçok bilgi ve fikirle dolu olacaktır. Eğer hemen sıradaki Sprint’e geçerlerse hiç kimse bu bil gileri

sindirme ve derslerden öğrenme şansı elde edemeyecektir. Ürün Sahibi, Sprint demo’sundan sonra

önceliklerini değiştirme şansı bulamayacaktır.

Kötü:

Bu kural sadece Scrum için değil hayat içinde geçerlidir! Örneğin eğer hayatımda boş zaman

olmasaydı, bu kitap olmazdı. Boş zaman verimlilik ve kişisel refah için hayati derecede önemlidir!

Eğer siz de takvimi sürekli dolu olan kişilerden biriyseniz, şunu deneyin: takviminizi açın bir

haftanın yarım gününe “boş zaman” yazın. Boş zaman içinde ne yapacağınıza önceden karar vermeyin. Neler olacak görün. :)

90

Yeni Sprint’e başlamadan önce boş zaman yaratmaya çalışıyoruz. Daha net olmak gerekirse Sprint

Retrospektif Toplantısı’ndan sonra ve Sprint Planlama Toplantısı’ndan önce. Gerçi her zaman başarılı

olamıyoruz ama olsun.

En azından Sprint Retrospektif ve Sprint Planlama Toplantıları’nın aynı gün olmamasına dikkat

ediyoruz. En azından herkes Sprint’siz bir gece uykusu uyuyabilmelidir.

İyi:

Daha iyi:

Boş zaman yaratmanın bir yolu laboratuvar günleri(ya da siz adını ne koymak istiyorsanız) olabilir.

Bugünlerde yazılım geliştiriciler canları ne isterse onu yapmaya izinlidirler.(Peki peki kabul ediyorum,

google’dan ilham aldım). Örneğin en son çıkan araçları ve API’leri araştırma, sertifika için çalışma, iş

arkadaşlarıyla teknoloji konusunda faydalı tartışmalar yapma, hobi için yaratılan bir projeyi kodlama

vb.

Hedefimiz her Sprint arasında bir laboratuvar gününe sahip olmak. Bu şekilde Sprint’ler arasında

doğal bir dinlenmeye sahip olursunuz. Ayrıca bilgilerini güncelleme şansına sahip bir geliştirme

takımınız olur. Artı potansiyel çalışanlar için oldukça çekici haktır.

En iyi?

Şu an ayda bir laboratuvar günümüz var, her ayın ilk Cuma günü. Neden Sprint’ler arasında değil?

Çünkü tüm şirketin aynı gün laboratuvar günü yapmasının önemli olduğunu düşündüm. Yoksa

91

insanlar bunu ciddiye almama eğilimindedirler. Ayrıca senkronize Sprint’lerimiz bulunmadığına göre

Sprint’leri baz almayan bir gün seçmeliydim.

İleride bir gün tüm ürünlerimiz için koştuğumuz Sprint’leri senkronize etmeyi deneyebiliriz. Bu

durumda iki Sprint arasında bir laboratuvar günümüz olabilir.

Spotify’daki birçok deneyden sonra şirket genelinde “hack weeks” yapmaya başladık. Yılda iki

defa tüm hafta canımız ne isterse onu ve sonunda bir demo bir de parti yapıyoruz. Tüm şirket

sadece teknoloji ekibi değil. Buradan çıkan yaratıcı fikirlerin tetiklediği yenilikçilik şaşırtıcı! Herkes

aynı anda yaptığı için takımlar arasındaki bağımlılık en aza inmiş oluyor. Spotify mühendislik

kültürü üzerine bir video yaptım, bu video da “hack weeks” ve daha birçok şeyi anlattım. Buradan

erişebilirsiniz: http://tinyurl.com/spotifyagile

92

Bölüm

Oniki

Teslim planlamasını ve sabit fiyat anlaşmalarını nasıl yapıyoruz?

Bazen bir Sprint’ten fazla önünüzü görmeniz gerekir. Sabit fiyatlı anlaşmaların yapıldığı ürünlerde

sadece önümüzdeki Sprint’i değil ileriki Sprint’leri de planlamak zorunda kalabiliriz.

Teslim planlaması yeni sistemin 1.0.0 versiyonu “ne zaman” teslim edilecek sorusunu

cevaplayabilmek için bir girişimdir.

Eğer teslim planlaması hakkında gerçekten bir şeyler öğrenmek istiyorsanız kitabımın bu bölümünü

atlayın ve Mike Cohn’un Agile Estimating and Planning kitabını okuyun. Keşke bu kitabı daha önce

okusaydım. Teslim planlamasıyla ilgili problemleri kendi kendimize çözdükten sonra bu kitabı

okudum. Benim durumumda teslim planlaması biraz daha basit fakat iyi bir başlangıç noktasıdır.

Kabul Eşiklerinizi Belirleyin

Geleneksel Ürün İş Listesi’ne ek olarak Ürün Sahibi kabul eşik listesini belirler. Ürün İş Listesi’ndeki

maddelerin önem seviyesini belirten basit bir sınıflandırmadır.

Aşağıda kabul eşiklerine örnek bulunuyor:

- Önem derecesi >= 100 olan bütün kullanıcı hikayeleri versiyon 1.0 içinde teslim edilmek

zorundadır yoksa ölümle cezalandırılırız.

- Önem derecesi 50-99 arasında olan kullanıcı hikayeleri versiyon 1.0’a dahil edilmelidir. Fakat

büyük teslimden sonra bu maddelerin içinde olacağı bazı küçük teslimler yapabiliriz.

Ayrıca Eric Ries’in Lean Startup kitabını da okuyabilirsiniz. Birçok projenin büyük bir teslim

planının önceden yapılması büyük problemdir. Bunun yerine küçük teslimlerin yapılması ve bu

teslimlerin belirlenen zamana uyup uymadığının ölçülmesi gerekir. Yalınlık eğer uygun şekilde uygulanırsa başarısızlık riskini ve maliyetini radikal bir şekilde düşürür.

93

- Önem derecesi 25-49 olanlar gereklidir. Fakat versiyon 1.1’de teslim edilebilirler.

- Önem derecesi < 25 olan maddeler spekülatiftir ve hiç gerek olmayabilir.

Yukarıdaki kurallara göre renklendirilmiş örnek bir Ürün İş Listesi:

Önem Derecesi Adı

130 Muz

120 Elma

115 Portakal

110 Guava

100 Armut

95 Üzüm

80 Fıstık

70 Donut

60 Soğan

40 Greyfurt

35 Papaya

10 Yaban mersini

10 Şeftali

Kırmızı: Versiyon 1.0’da kesinlikle olması gerekenler.

Sarı: Versiyon 1.0’a eklenmesi iyi olanlar.

Yeşil: Belki daha sonra yapılır.

Yani bitiş tarihine kadar Kırmızıları ve Sarıları bitirebilirsek güvendeyiz demektir. Eğer zaman

yetmezse Sarılardan bazılarını atlayabiliriz. Yeşil olanları hepsi bonus.

Bu analizi numerik değerler vermeden de yapabilirsiniz! Sadece listeyi sıralayın.

94

En Önemli İş Maddelerinin Zaman Tahmini

Teslim planı yapabilmek için Ürün Sahibi‘nin tahminlere ihtiyacı vardır, en azından kontratta yer alan

bütün maddeler için. Sprint Planlama gibi bu da Ürün Sahibi ve Takım arasında iş birliği içinde

yapılması gereken bir şeydir. Ürün Sahibi iş maddelerini açıklar, soruları cevaplar ve Takım işlerin

büyüklük tahmini yapar.

Zaman bazlı tahminde bulunmak eğer gerçeğe yakın değerler verebiliyorsanız değerlidir. Eğer

gerçeğe yakın tahminde bulunamıyorsanız değeri azdır. Eğer gerçekle uzaktan yakından ilişkisi yoksa

tahminde bulunmak tamamıyla değersizdir.

Kimin ne kadar süre harcadığı ilişkisini kurarak işlerin büyüklüğünü zaman bazında tahmin etmenin

değeri(kendi düşüncem):

Aslında bu kadar uzatıp söylemeye çalıştığım şey:

- İşlerin büyüklüğünü tahmin etme işini Takım’a bırakın.

- Bunun için çok fazla zaman harcamamalarını söyleyin.

- Tahminlerin sadece kaba bir tahmin olduğunu ve bir söz verme olmadığını anladıklarından

emin olun.

Genelde Ürün Sahibi tüm takım üyelerini bir odaya toplar, iş maddelerini hatırlatır ve Takıma bu

toplantının amacının Ürün İş Listesi’nde en üstteki 20 iş maddesinin zaman tahminlerinin verilmesi

olduğunu söyler. Ürün Sahibi, her bir kullanıcı hikayesinin üstünden geçer ve Takımın işini yapmasına

izin verir. Soruları cevaplamak ve net olmayan kullanıcı hikayelerinin kapsamını belirtmek için Ürün

Sahibi oda da bulunur. Sprint Planlama’da olduğu gibi yanlış anlaşılma riskini azaltmak için “Nasıl

demo yapacağız?” alanı oldukça kullanışlıdır.

Bu toplantının süresine uyulmalıdır yoksa Takım birkaç kullanıcı hikayesini büyüklük tahmini vermek

için çok fazla zaman harcayabilir.

95

Eğer Ürün Sahibi bu konu üzerine daha fazla zaman harcanması gerektiğini düşünüyorsa daha sonra

başka bir toplantı da ayarlayabilir. Geliştirme Takımı, bu toplantıların içinde bulunulan Sprint’e etkisi

olduğunu Ürün Sahibi’ne söylemeli ve etkisini anladığından emin olmalıdır.

İşlerin büyüklüğünü hikaye puanı bazında tahmin etme aşağıdaki gibi bitebilir:

Önem Derecesi Adı Tahmin

130 Muz 12

120 Elma 9

115 Portakal 20

110 Guava 8

100 Armut 20

95 Üzüm 12

80 Fıstık 10

70 Donut 8

60 Soğan 10

40 Greyfurt 14

35 Papaya 4

10 Yaban mersini

10 Şeftali

Takım Hızını Tahmin Etme

Şimdi önceliği en yüksek kullanıcı hikayeleri için kaba zaman tahminine sahibiz.

Sıra Sprint başına ortalama takım hızını tahmin etmede.

Bunun anlamı odak çarpanımızın kaç olduğuna karar vermektir.

“Zaman tahmini” olarak adlandırma oldukça kafa karıştırıcı halbuki “büyüklük tahmini” ifadesini

kullanabilirmişim. Muz’un ne kadar süreceğini bilemem fakat Elma’dan fazla Portakal’dan çok

daha kısa süreceğinden eminim. Tamamıyla yanlış olmaktansa kabaca doğru olmak daha iyidir.

Lanet olsun şu odak çarpanına...

96

Odak çarpanı temelde Takım’ın Sprint’e aldığı işlere ne kadar zaman ayıracağıdır. Hiçbir zaman %100

değildir çünkü planlanmamış işlere, aynı anda birden fazla iş yapmaya, diğer takımlara desteğe, e-

postalarına bakmaya, bilgisayarlarını iyileştirmeye ve mutfakta politika konuşmaya zaman ayırmak

zorundadır.

Diyelim ki odak çarpanının %50 olmasına karar verdik(bu örnek oldukça düşük, takımımızda ortalama

%70 civarında), Sprint’lerimiz ise 3 haftalık(15 iş günü) ve Geliştirme Takımı’mız 6 kişiden oluşuyor.

Her Sprint ortalama 90 adam/gün demektir fakat 45 adam/gün’lük kullanıcı hikayesi bitirilmesi

beklenmektedir. Yani tahmini takım hızımız 45 hikaye puanıdır.

Eğer her bir kullanıcı hikayesinin beş gün süreceğine dair zaman tahmininiz varsa o zaman bu takım

bir Sprint’te dokuz kullanıcı hikayesini bitirebilir demektir.

Her Şeyi Teslim Planında Birleştirme

Şimdi elimizde zaman tahmini ve takım hızı(45) var. Ürün İş Listesi’ni hızlıca Sprint’lere bölebiliriz.

Önem Derecesi Adı Tahmin

Sprint 1

130 Muz 12

120 Elma 9

115 Portakal 20

Sprint 2

110 Guava 8

100 Armut 20

95 Üzüm 12

Odak çarpanını atlayın. Takıma listeye göz atmasını söyleyin ve Sprint’te listeden ne kadar iş

alabilecekleri konusunda iyi bir tahminde bulunmalarını isteyin. Hikaye puanlarını toplayın. Bu odak çarpanını hesaplamaktan daha hızlı ve doğruya daha yakın/uzak olacaktır.

97

Sprint 3

80 Fıstık 10

70 Donut 8

60 Soğan 10

40 Greyfurt 14

Sprint 4

35 Papaya 4

10 Yaban mersini

10 Şeftali

Her bir Sprint tahmini takım hızı olan 45 hikaye puanını aşmayacak şekilde kullanıcı hikayesi içeriyor.

Şimdi görebiliyoruz ki sahip olmamız gereken bütün özellikleri(kırmızılar ve sarılar) 3 Sprint’te

geliştirebiliyoruz.

3 Sprint = 9 Hafta = 2 Ay

Bu müşteriye söz verdiğimiz bitiş tarihi mi? Kötü tahminlerden, beklenmeyen problemlerden, acil

gelen işlerden zarar görmemek için fazlasıyla boş vakit ayırmaya çalışırız. Bu durumda teslim tarihini

üç ay sonra olacak şekilde belirleyebiliriz.

Hepsi: Bu kullanıcı hikayelerinin hepsi bitmiş olacak takım hızımız(30) düşük olsa bile.

Bazıları: Bu kullanıcı hikayelerinin bazıları bitecek fakat tamamı bitmeyecek.

Güzel olan şey her üç haftada bir müşteriye kullanılabilir bir şey göstermemiz ve biz geliştirdikçe

isterse ihtiyaçlarını değiştirebilmesidir.(Bu seçenek tabi ki kontratın nasıl olduğuna bağlı)

Hiç biri: Bu kullanıcı hikayelerinin hiçbiri bitmeyecek, takım hızımız(50) yüksek olsa bile.

Buna alternatif olan ve iyi işleyen bir yol: Tahmini takım hızını (30-50) aralığı olarak belirleyin.

Daha sonra Ürün İş Listesi’ni 3 listeye bölün.

98

Teslim Planını Uyarlama

Gerçekler kendini plana uyarlamaz! Bu nedenle planlar gerçeğe uyarlanmalıdır.

Her Sprint’ten sonra o Sprint’teki gerçek takım hızımıza bakarız. Eğer gerçek takım hızımız tahmin

ettiğimiz takım hızından çok farklıysa gelecek Sprint’ler için tahmini takım hızımızı gözden geçiririz ve

teslim planını güncelleriz. Eğer bu, teslim tarihini zora sokarsa Ürün Sahibi, müşteriyle pazarlığa

başlayabilir ya da kapsamın nasıl daraltılabileceğini kontrol edebilir. Daha güzeli Ürün Sahibi ya da

Takımın takım hızını artırmak için yeni bir fikri olabilir ya da odak çarpanını artırmak için bazı ciddi

engellerin ortadan kaldırılması denenebilir.

Ürün Sahibi, müşteriyi arayabilir ve şöyle diyebilir:

“Selam, tahminimizin biraz gerisinde kalıyoruz fakat çok fazla zamanımızı alacak Pac-Man özelliğini

kaldırırsak bitiş tarihine yetişebiliriz. Eğer isterseniz bitiş tarihinden sonraki ilk Sprint bu özelliği

ekleyebiliriz.”

Müşteri için iyi bir haber olmayabilir fakat en azından dürüstüz ve müşteriye erkenden seçim şansı

verdik. Önceliği yüksek işleri zamanında teslim etmek mi yoksa her şeyi geç teslim etmek mi?

Genelde zor bir seçim değildir. :)

Agile Product Ownership in a Nutshell(Özetle Çevik Ürün Sahipliği) adında 15 dakikalık bir video

yaptım. Scrum’da Ürün İş Listesi yönetimi ve teslim planlamasıyla ilgili kullanışlı birçok ipucu içeriyor. http://tinyurl.com/ponutshell

99

Bölüm

Onüç

Scrum ve XP’yi Beraber Nasıl Kullanıyoruz?

Scrum ve XP(eXtreme Programming) çok verimli bir şekilde beraber kullanılabilir. İnternette

gördüğüm birçok şey bu hipotezi destekliyor. Bu yüzden “neden” sorusuna hiç girmeyeceğim.

Sadece bir şeyden bahsedeceğim. Scrum, yönetimsel ve organizasyonel pratiklere odaklanırken XP

gerçek programlama pratiklerine odaklanır. Bu nedenle ikisinin karışımı oldukça başarılı olur. Farklı

alanlardaki problemleri çözerler ve birbirlerini tamamlarlar.

Scrum ve XP çok verimli bir şekilde beraber kullanılabilir!

XP pratiklerinden bazılarını günlük işlerimize nasıl uyguladığımızı anlatacağım. Takımlarımızın hepsi

XP pratiklerinin tamamını benimsemiş değil. Fakat toplama baktığımızda XP/Scrum kombinasyonunu

çok farklı açılardan deneyimleme şansı elde ettik. Bazı XP pratikleri, Scrum’da hali hazırda kullanılan

pratiklerdir. Örneğin tüm takım, beraber oturma, kullanıcı hikayeleri, poker planlama. Eğer birbirinin

üstüne geçen pratikler varsa Scrum versiyonunu kullandık.

Eşli Programlama

Son zamanlarda takımlarımızdan birinde bu pratiği uygulamaya başladık. Oldukça iyi çalışan bir

pratiktir. Diğer takımlarımızın çoğu eşli programlama yapmıyor. Eşli programlama yapan takımımızsa

Jeff Sutherland’ten Scrum ilk ortaya çıktığında XP pratiklerinin hepsini barındırdığını öğrendim.

Fakat Ken Schwaber mühendislik pratiklerinin Scrum içinde olmaması gerektiğine Jeff’i ikna

etmiş. Böylece hem Scrum modeli basitleşmiş oldu hem de takımlar teknik pratiklerin

sorumluluklarını kendileri almış oldu. Belki de Scrum’ın bu kadar hızlı yayılmasının neden i budur.

İşin kötü tarafı birçok takımın teknik pratiklerin eksikliğinden kaynaklı sürdürülebilir Çevik yazılım geliştirme yapamamalarıdır.

100

sadece birkaç Sprint’tir bu pratiği deneyimliyor. Diğer takımlarında bu pratiği deneyimlemesi için

koçluk veriyorum.

Eşli programlama konusunda şimdiye kadar gözlemlediklerim:

- Eşli programlama kod kalitesini geliştirir.

- Eşli programlama takımın odağını geliştirir.

- Şaşırtıcı bir şekilde eşli programlamayı denemeyen birçok yazılımcı eşli programlamaya

karşıdır. Eğer denerlerse de çok hoşlarına gider.

- Eşli programlama yorucudur ve tüm gün yapılmamalıdır.

- Eşleri sıkça değiştirmek iyidir.

- Eşli programlamayla bilgi dağılımı gelişir ve yine şaşırtıcı bir şekilde bu hızlı olur.

- Bazı insanlar eşli programlama yapmaktan hoşlanmazlar. Eşli programlama yapmaktan

hoşlanmıyor diye iyi bir yazılımcıdan vazgeçmeyin, bazı insanlar sadece hoşlanmıyor

olabilirler.

- Kod değerlendirme(Code Review), eşli programlamaya bir alternatif olabilir.

- Gözlemci’nin(klavyeyi kullanmayan kişi) kendi bilgisayarı olmalıdır. Sürücü(klavyeyi kullanan

kişi) tıkandığı zaman Gözlemci kendi bilgisayarından hızlıca araştırma yapabilmeli,

dokümanlara bakabilmelidir. Bu nedenle Gözlemci’nin de kendi bilgisayarı olmalıdır.

- İnsanları eşli programlama yapmaya zorlamayın. İnsanları cesaretlendirin ve doğru araçlara

sahip olmalarını sağlayın fakat kendi kendilerine deneyimlemelerine izin verin.

Test Yönelimli Geliştirme(Test Driven Development)

Bu, benim için Scrum’dan ve XP’den daha önemlidir. Evimi, televizyonumu ve köpeğimi alabilirsiniz

fakat TYG yapmamı engellemeye çalışmayın. Eğer TYG’den hoşlanmıyorsanız ofisinize girmeme izin

vermeyin çünkü öyle ya da böyle ofisinizde TYG yapmaya başlayacağım.

İşte 10 saniyede TYG’nin özeti:

Test Yönelimli Geliştirme’nin anlamı otomatize bir test yazarsınız daha sonra sadece o testi geçecek

kadar kodu yazarsınız. Sonrasındaysa kodunuzu gözden geçirir, okunabilirliğini iyileştirir ve fazla

kodları temizlersiniz. Cilala ve parlat!

Artık TYG konusunda bu kadar bağnaz değilim. Anladım ki TYG oldukça niş bir teknik ve çok az

insan ustası olacak kadar sabırlı. Artık sadece teknikleri öğretirim ve takımlar ne kadar yapmak

istiyorlarsa yaparlar.

101

TYG üzerine düşüncelerim:

- TYG zordur. Anlaması zaman alır. Aslında birçok durumda ne kadar öğrettiğiniz, koçluk

yaptığınız ve gösterdiğiniz önemli değildir. Bir yazılımcının TYG’yi anlayabilmesinin en güzel

yolu TYG’yi iyi bilen başka bir yazılımcıyla eşli programlama yapmasıdır. Yazılımcı bir kere

öğrendiğinde muhtemelen ciddi bir şekilde bulaşıcı hastalığa yakalanacaktır. Bir daha başka

bir şekilde kod yazmak istemeyecektir.

- Sistem tasarımı üzerinde derin bir etkisi vardır.

- TYG’yi anlama ve yeni bir ürün üzerinde verimli şekilde kullanma ve özellikle kara kutu

entegrasyon testleri zaman alacaktır fakat yatırım getirisi oldukça hızlı geri dönecektir.

- Testleri yazabilmek için yeterli zamanı ayırdığınızdan emin olun. Bunun anlamı doğru araçları

bulma, insanları eğitme ve doğru ana sınıfları temin etme olarak düşünülebilir.

1) Her önemli özelliğin uçtan uca en az bir kere test edildiğinden emin olun.

2) Karmaşık ya da iş birimi açısından kritik kodların otomatize edilmiş birim testlerinin

yapıldığından emin olun.

3) Testleri yazılmamış kodlar olabilir, sorun yok. Fakat hangi kodların testlerinin

yazılmadığından haberdar olun. Testini yazmadığınız kodların testini yazmak manuel olarak

yapmaktan daha maliyetliyse bu testleri manuel yapın fakat ihmalkarlık yaparak testleri

atlamayın.

4) İlerledikçe testleri yazın, testleri yazmayı en sona bırakmayın. Daha sonra da şimdi olduğunuz

kadar meşgul olacaksınız.

TYG için aşağıdaki araçları kullanıyoruz:

- jUnit/httpUnit/jWebUnit kullanıyoruz. TestNG ve Selenium’u kullanmayı düşünüyoruz.

- HSQLDB test amaçlı gömülü bellek veritabanı olarak kullanıyoruz.

- Jetty test amaçlı gömülü bellek konteynırı olarak kullanıyoruz.

- Test kapsam metrikleri için Cobertura’yı kullanıyoruz.

TYG çok zor olduğu için insanları yapmaları için zorlamam. Bunun yerine aşağıdaki ilkeler çerçevesinde koçluk ederim:

TYG bağnazlığı yapmadan yeterince bilgi verdim gibi görünüyor. Test yazmanın getirisi zamanla

azaldığı için test kapsamı* genelde %70 oranlarında kalır. Özetlersem test otomasyonu hayatidir,

TYG ise seçenektir.

*Test coverage ifadesinin karşıl ığı olarak test kapsamı ifadesini kullandım.

102

- Farklı test tiplerini(mock’la, mock’sız, harici veritabanı, entegre veritabanı) birbirine

bağlamak için Spring’i kullanıyoruz.

En gelişmiş ürünlerimizde(TYG açısından) otomatize edilmiş kara kutu(black box) kabul testleri vardır.

Bu testler tüm sistemi bellek, veritabanı ve web server’larını da içine alacak şekilde ayağa kaldırır.

Sisteme http üzerinden erişir tıpkı ürün kullanıma açıldığında olacağı gibi.

Yukarıdaki araçlar kullanılarak oldukça hızlı geliştir-derle-test et döngüleri kurulabilir. Yazılım

geliştiricilere kodu iyileştirmekten çekinmemeleri için güven de verir. Bunun anlamı da tasarım temiz

ve basit kalır, sisteminizin ne kadar büyüdüğünün önemi yoktur.

Yeni Projelerde TYG

Ürünün ilk kurulumunu geciktirse bile yeni yazdığımız bütün kodları TYG ile yazıyoruz. Yararları o

kadar çok ki TYG yapmamak için bir bahane yok.

Eski Projelerde TYG

TYG yapmak zordur fakat en başta TYG düşünülerek yazılmamış bir kodu TYG kullanarak devam

ettirmek gerçekten zordur! Neden? Çünkü… Bu konu hakkında sayfalarca yazabilirim. Burada

duruyorum. TDD from Trenches kitabıma saklıyorum. :)

Karmaşık sistemlerimizden biri için otomatize edilmiş entegrasyon testleri çok fazla zaman harcadık.

Kodlar uzun süre önce yazılmış, ciddi anlamdan karmaşık ve hiç testi yazılmamış bir sistemdi.

Sistemin her tesliminde tam zamanlı testçilerden oluşan bir takım bir sürü regresyon ve performans

testi yapıyordu. Regresyon testlerinin büyük çoğunluğu manuel’di. Bu, gelişt irme ve teslim

döngümüzü oldukça yavaşlattı. Hedefimiz bu testleri otomatize etmekti. Birkaç ay kafamızı duvarlara

vurduktan sonra yine de hedefimize yaklaşmış değildik.

Bu birkaç aydan sonra yaklaşımımızı değiştirdik. “Manuel test sürecine nasıl daha az zaman

harcarız?” diye sormak yerine manuel regresyon testlerinin başımıza bela olduğu gerçeğini

Bu kitabı yazabilmek için hiç zamanım olmadı. Gerçi TYG üzerine yazılmış birçok kitap zaten var.

En iyilerinden biri de Michael Feathers’ın yazdığı Working Effectively with Legacy Code kitabıdır. Ayrıca teknik borç konusunda birkaç makalem bulunuyor. Blog’uma bakabilirsiniz.

http://blog.crisp.se/tag/technical-debt

Bu şekilde çalışma şu an eskiden olduğundan çok daha kolay çünkü birçok iyi test aracı ve framework var. TYG yapın ya da yapmayın bu araçlar oldukça yararlıdır.

103

kabullendik. Bu, bir oyun sistemiydi ve test takımının büyük bir zamanının önemsiz kurulum

işlerine(test amaçlı turnuvaların hazırlanması ya da planlanmış bir turnuvayı bekleme gibi)

harcandığını fark ettik. Bunun için yardımcı araçlar geliştirdik. Küçük ve kolayca erişilebilir kısa yollar

ve script’ler, testçilerin üzerindeki gereksiz işleri almamızı sağladı ve testçilere gerçek test işleri kaldı.

Bu efora gerçekten değdi. Aslında belki de en başta yapmamız gereken buydu. Testleri otomatize

etmeye o kadar kararlıydık ki adım adım gerçek hedefimizi unuttuk. Aslında ilk adım manuel testlerin

daha verimli bir şekilde yapılmasıydı.

Ders: Eğer manuel test yapma konusuna takıldıysanız ve bu şekilde otomatize etmek istiyorsanız,

yapmayın! Bunun yerine regresyon testlerini kolaylaştıracak şeyler yapın. Daha sonra tüm test

sistemini otomatize etmeyi düşünün.

Artımlı Tasarım

Bunun anlamı tasarımı en başta basit tutmak ve sürekli olarak iyileştirmektir. Yani her şeyi en baştan

düşünüp daha sonra da bu yapıyı dondurmak değildir.

Bu konuda oldukça iyiyiz. Var olan tasarımı iyileştirmek ve geliştirmek için makul zaman ayırırız ve

tasarım çalışmalarının başında çok az zaman harcarız. Elbet yanıldığımız zamanlar oluyor. Örneğin

zayıf bir tasarımın çok fazla derinine inerek iyileştirme işi büyük bir projeye dönüşebiliyor. Sonuç

olarak biz oldukça memnunuz.

Sürekli tasarım iyileştirmeleri TYG yapmanın bir yan etkisidir.

Sürekli Entegrasyon

Ürünlerimizin büyük çoğunluğunda Maven ve QuickBuild tabanlı sürekli entegrasyon yapısı bulunur.

Bu hayati derecede önemli ve zaman kazandırıcıdır. “Ama benim makinemde çalışıyor” konusunun

nihai çözümüdür. Sürekli derleme bilgisayarımız yargıç gibidir, kod tabanımızın sağlığı için bir

referans noktası görevi görür. Biri versiyon kontrol sistemine kodunu gönderdiğinde sürekli derleme

bilgisayarımız uyanır ve her şeyi en baştan paylaşımlı bir bilgisayar üzerinde derler ve tüm testleri

koşar. Eğer herhangi bir şey yanlış giderse derlemenin başarısız olduğuna dair tüm takıma

bilgilendirici bir eposta gönderir. Bu eposta içinde hangi kod değişikliğinin derlemeyi bozduğuna dair

bilgi ve test raporlarının bir bağlantısı bulunur.

104

Her akşam sürekli entegrasyon bilgisayarı ürünü en baştan oluşturur ve binary dosyaları(ear’lar,

war’lar vb), dokümanları, test raporlarını, test kapsam raporlarını ve bağımlılık raporlarını doküman

portalımız üzerinde yeniden yaratır.

Bu yapıyı kurmak büyük bir işti fakat her dakikasına değdi.

Ortak Kod Sahipliği

Ortak kod sahipliği için takımları cesaretlendiririz fakat takımlarımızın tamamı bunu benimseyebilmiş

değil. Eşli programlama ve eşli programlama da eşlerin sürekli olarak değişmesiyle “ortak kod

sahipliğinin” kendiliğinden yükseldiğini fark ettik. Ortak kod sahipliği konusunda iyi takımların çok

güçlü olduklarını gördüm. Örneğin takımdaki önemli kişilerden biri hasta olduğu için Sprint kendi

haline bırakılmaz.

Bilgilendirici Çalışma Alanı

Tüm takımların beyaz tahtası, boş duvarları vardır ve bunları çok iyi kullanırlar. Birçok oda da ürün ve

proje hakkında bilgilerle donatılmış duvarlar bulursunuz. En büyük problem duvarda biriken eski

bilgilerdir. Belki de her takımda bir temizlikçi rolü oluşturmalıyız.

Scrum Duvarları’nın kullanılması için takımları cesaretlendiririz fakat tüm takımlarımız bu pratiği

benimsemiş değildir.

Bunu bir adım ileri taşırsanız sürekli teslime ulaşmış olursunuz. Kaynak sisteme gönderilen her

kod bir teslim olabilir ve teslim sadece bir tıklamayla yapılacak bir işe dönüşür. Bunu yapan takım

sayısı her gün artıyor ve kişisel projelerimde ben de kullanıyorum. Oldukça verimli ve güzel bir

yol. Continuous Delivery kitabını okumanızı(en azından araştırmanızı) öneririm. Bu yapıyı kurmak

büyük bir iş fakat yeni bir ürün geliştirmeye başladığınızda bunu yapmaya değer. Anında kazanç

sağlamaya başlarsınız ve şimdilerde bunu destekleyen harika araçlar var.

Spotify(ve hızla büyüyen birçok şirket) içlerinde “açık kaynak” modeline sahiptir. Kodun tamamı

dahili bir GitHub üzerinde bulunur ve çalışanlar repo’ları kopyalayabilir tıpkı halka açık olan açık

kaynak kodlar gibi sadece şirket içinde.

105

Kodlama Standartları

Son günlerde kodlama standartlarını belirlemeye başladık. Oldukça yararlı keşke daha önce

yapsaydık. Neredeyse hiç zaman almıyor, önemli olan şey basit başlamak ve kendiliğinden

büyümesine izin vermek. Herkes için anlaşılır olmayan noktaları belirleyin ve yazın daha sonra var

olan bir materyale bağlantı kurun.

Her yazılım geliştiricinin kendine has bir kodlama şekli vardır. Ürün içinde oluşabilecek hataları nasıl

yakalarlar, koda yorumu nasıl yazarlar, ne zaman null değer dönerler vb. belirleyin. Kod standardının

olmaması bazı durumlarda önemli değildir fakat bazı durumlardaysa sistem tasarımında ciddi

tutarsızlıklara ve okuması zor koda neden olabilir. Kod standardı burada oldukça yararlı yeter ki

önemli şeylere odaklanın.

Kod standartlarımızdan bazı örnekler:

- Herhangi bir kuralı bozabilirsiniz fakat bunu yapmak için iyi bir nedeniniz olduğundan ve

bunu dokümante ettiğinizden emin olun.

- Varsayılan olarak Sun’ın kod düzeni kurallarını kullanırız: http://java.sun.com/docs/

codeconv/html/CodeConvTOC.doc.html

- Asla ama asla stack trace’i loglamadan bir hatayı yakalama. rethrowing.log.debug() yapılabilir

yeter ki stack trace’i kaybetme.

- Sınıfları birbirinden ayırmak için “setter” bazlı bağımlılık yönetimini kullan(sınıflar arası

bağlantı isteniyorsa elbette bunu kullanma)

- Kısaltmalar yapma. DAO gibi çok bilinen kısaltmalar kullanılabilir.

- Collection’lar veya diziler null dönmemelidir. Null yerine boş Collection ya da dizi dön.

Sürdürülebilir Hız / Enerjik İş

Çevik yazılım geliştirme üzerine yazılmış birçok kitap haddinden fazla mesainin yazılım geliştirmede

ters etki yaptığını iddia eder.

Gönülsüzce yapılan bir deneyden sonra buna tüm kalbimle katılıyorum!

Kodlama standartları ve stil kılavuzları harika bir araçtır. Fakat tekeri yeniden icat etmeye gerek

yoktur. Arkadaşım Google’dan bir tane kopyalayabilirsiniz:

https://github.com/google/styleguide

106

Yaklaşık olarak bir yıl önce takımlarımızdan biri(en büyüğü) çılgınca mesai yapıyordu. Kod kalitesi

sıkıntılıydı ve zamanlarının çoğunu yangını söndürmekle uğraşıyorlardı. En iyi takım(ki bu takımda

fazla mesai yapıyordu) ciddi kalite testlerinin çoğunu yapabilecek şansı bulamadı. Kullanıcılarımız

sinirli bazı dergiler bizi canlı canlı yiyordu.

Birkaç aydan sonra insanların çalışma saatlerini uygun oranda düşürmeyi başardık. İnsanlar normal

saatlerde çalıştılar(projenin çatırdağı zamanlar hariç). Süprizzzzzz! Verimlilik ve kalite gözle görülür

bir şekilde iyileşti.

Elbette çalışma saatlerini düşürme iyileştirme için tek yol değildir fakat bu iyileştirmede büyük etkisi

olduğunu düşünüyoruz.

Bunu sürekli görüyorum. Yazılım geliştirmede(karmaşık ve yaratıcıl ık gerektiren herhangi bir işte)

çalışılan saatler ve üretilen değer arasındaki bağlantı çok küçüktür. Önemli olan şey odaklanılmış ve

motive olunmuş saatlerdir. Birçoğumuz Cumartesi sabahlamayı ve huzur ve sessizlik içinde birkaç

saati, bütün bir haftanın işini tamamlamayı deneyimlemiştir. Odaklanmakla ve motive olmakla

kastettiğim budur. Yani birkaç istisna dışında insanları fazla mesai yapmaları için zorlamayın. Artı

insanları yakmak şeytanicedir!

107

Bölüm

Ondört

Nasıl Test Yapıyoruz?

En zor bölüm! Scrum’ın mı yoksa genel olarak yazılım geliştirmenin mi en zor bölümü olduğundan

emin değilim.

Farklı organizasyonlarda muhtemelen en çok çeşitlilik olan bölüm testtir. Kaç testçiniz olduğuna, test

otomasyonunu ne kadar kullandığınıza, ne tip bir sisteminiz olduğuna, teslim döngünüzün

uzunluğuna, yazılımınızın(blog, uçuş kontrol sistemi) ne kadar kritik olduğuna bağlıdır.

Scrum’da test nasıl yapılır konusunda birçok deneyimimiz oldu. Şimdiye kadar neler yaptığımızı ve

neler öğrendiğimizi anlatmaya çalışacağım.

Muhtemelen Kabul Testi Aşamasından Kurtulamazsınız

İdeal Scrum dünyasında bir Sprint’in sonunda sisteminizin teslim edilebilir bir versiyonunu elde

edersiniz. Sadece teslim edilir, değil mi?

Kesinlikle!

108

Yanlış!

Tecrübelerimize göre bu yöntem pek işlemiyor. Hatalar olacaktır. Eğer kalite sizin için değerliyse bir

çeşit manuel kabul testi aşaması gereklidir.

Bu aşama Scrum Takımı’nın düşünemediği, yeterli yetkinlikler olmadığı, zamanı olmadığı aşamadır.

Testçiler tıpkı son kullanıcıların erişeceği şekilde sisteme erişirler, bunun anlamı da testin manuel

olmasıdır(sisteminizin insanlar tarafından kullanılacağını varsayıyorum).

Test takımı hataları bulur, Scrum Takımı hataları düzeltmek zorunda kalacaktır. Er ya da geç umarım

erkenden hataların temizlendiği versiyon olan 1.0.1’i son kullanıcılara teslim edebileceksiniz.

Kabul test aşaması dediğimde üretim ortamına teslim yapılabilecek kadar iyi bir versiyon elde

edinceye kadar geçen süreyi kastediyorum.

Nasıl yani?

Ne saçmalık! Bunu yazdığıma inanamıyorum! Ve bu kitap patladı ve dünyanın her yerinde okuyanlar sözlerime inandı. Yazık bana! Köööötü yazar, bir daha bunu yapma! *tokat*

Evet manuel test önemli ve bir ölçüde kaçınılmaz. Fakat Sprint içinde Takım tarafından yapılmalı

başka bir gruba bu iş yaptırılmamalı ya da gelecekte bir test aşaması olmamalı. Bu yüzden Waterfall’dan kurtulmaya çalışıyoruz, hatırladınız mı?

109

Kabul Testi Aşamasını En Aza İndirme

Kabul testi aşaması can yakar! Çevik olduğunuzu hissetmezsiniz!

Kesinlikle! Bu yüzden yapmayın.

Eğer kabul testi aşamasından kurtulamıyorsak en az seviyeye indirmeye çalışabiliriz. Daha açık

söylemek gerekiyorsa kabul testi aşaması için gerekli olan zamanı en az seviyeye indirebiliriz.

Aşağıdaki gibi yapabiliriz:

- Scrum Takımı tarafından geliştirilen kodun kalitesini en yüksek seviyeye çıkararak.

- Manuel yapılan testin verimliliğini artırarak(en iyi testçileri bularak, en iyi araçları

belirleyerek, fazla zaman harcanan testlerin otomatize edilmesini sağlayarak).

Peki, kodun kalitesini nasıl artırabiliriz? Birçok yol var. Aşağıda bizim bulduğumuz ve iyi çalıştığınız

düşündüğümüz iki yol var:

- Testçileri Scrum Takımı’nın bir üyesi yapın.

- Sprint içinde daha az kod yazma işi yapın.

Testçileri Scrum Takımı’nın İçine Yerleştirerek Kaliteyi Artırma

İki itirazı da duyuyorum:

- “Ama bu gayet açık! Scrum Takımları çapraz fonksiyonel olmalı!”

- “Scrum Takımları rolsüz olmalı, içinde analist, testçi, kodçu gibi alt roller olmamalı. Sadece

test yapan biri takımda olamaz.”

İzin verin açıklayayım. “Testçi” ile anlatmak istediğim şey birincil yetkinliği test yapmak olan biridir,

sadece test yapan biri değil.

Bazı ortamlarda kaçınılmaz görülebilir, biliyorum. Söylemek istediğim şey ben de kaçınılmaz

olduğunu düşünüyordum. Fakat şimdi gerçekten Çevik şirketlerin hızlı ilerlediklerini ve ayrı bir

kabul aşaması testinden kurtularak kalitelerini artırdıklarını, bu işleri Sprint içinde nasıl

yaptıklarını gördüm. Yani siz de kaçınılmaz olduğunu düşünüyorsanız belki içinde bulunduğunuz

durumdan kör olmuşsunuzdur ve göremiyorsunuzdur, tıpkı benim gibi. Her şeye rağmen bu

bölümde ayrı bir kabul testi aşamasını nasıl gerçekleştirebileceğinize dair yararlı bilgiler

bulacaksınız. Sprint’lerinizde kabul testlerinizi yapacak seviyeye gelene kadar bu bölümdeki bilgileri kullanabilirsiniz. :)

110

Geliştiriciler genelde çok kötü testçilerdir özellikle kendi geliştirdiği kodu test eden geliştiriciler.

Testçi, Onay Veren Adam

“Sadece” takım üyesi olmasının yanında testçinin önemli bir görevi daha vardır. Onay veren adamdır.

O söyleyene kadar Sprint içindeki hiç bir iş BİTTİ sayılmaz. Geliştiricilerin bir şey bitmediği halde

bittiğini söylediklerini çok gördüm. Çok net bir “Bitti Tanımınız” olsa bile geliştiriciler bunu genelde

unuturlar. Biz, yazılım geliştiriciler sabırsız insanlarızdır ve bir an önce sıradaki işe geçmek isteriz.

O zaman Testçi bir işin bitip bitmediğini nasıl biliyor? Her şeyden önce bitirilen işin testini yapmalı :)

Birçok durumda geliştiricinin bittiğini düşündüğü işin aslında test edilebilir durumda bile olmadığı

ortaya çıkar. Çünkü kod, test ortamına gönderilmemiştir. Testçi geliştirilen işlevselliği test ederken

Bitti Tanımı’nın kontrol listesi üzerinden bir geliştiriciyle beraber geçmelidir. Örneğin; eğer Bitti

Tanımı’nda teslim notu(release note) zorunluysa o zaman Testçi’nin teslim notunun olup olmadığını

kontrol etmesi gerekir. Bitti Tanımı’nın dışında kontrol edilmesi gereken başka şeyler varsa Testçi

bunların kontrolünü de yapar fakat bizim durumumuzda bu nadirdir.

Bunun güzel bir yan etkisi Sprint demosunu yapmaya uygun birinin olmasıdır.

Test Yapılacak Bir şey Olmadığında Testçi Ne Yapar?

Bu soru sürekli soruluyor. Testçi: “Şu an test edilecek bir şey yok, ne yapmalıyım?” İlk kullanıcı

hikayesinin tamamlanması bir hafta alabilir, peki bu süre boyunca Testçi ne yapmalı?

Öncelikle testler için hazırlanmalı. Test senaryolarını yazmalı, test ortamını hazırlamalı vb. Böylece bir

geliştirici bir kullanıcı hikayesini bitirdiğinde ve bu kullanıcı hikayesinin test edilmesi gerektiğinde

beklememeli. Testçi işe dalmalı ve test yapmaya başlamalıdır.

Artık Onay Veren Adam modelinin o kadar da hayranı değilim. Darboğaz oluşmasına ve bir kişinin

çok fazla sorumluluk üstlenmesine neden olur. Fakat bazı şartlar altında faydalı olabileceğini düşünüyorum. Ayrıca eğer kaliteye biri onay verecekse bu gerçek bir kullanıcı olmalıdır.

Bu çok önemli bir konudur. “Çapraz fonksiyonel” herkesin her şeyi bilmesi anlamına gelmez.

Herkesin uzmanı olduğu konudan fazlasını yapmaya gönüllü olmasıdır. Uzmanlıkların ve çapraz

fonksiyonel olmanın güzel bir karışımına sahip olmak isteriz. Yani ürünün kalitesinden Geliştirme

Takımı’nın tamamı sorumludur. Bu nedenle herkes test yapacaktır. Testçi test yapma işine

rehberlik edecektir, test otomasyonu konusunda geliştiricilerle eş olacak ve daha karmaşık testleri kendi manuel yapacaktır.

111

Eğer Takım TYG yapıyorsa geliştiriciler ilk günden itibaren test yazmaya başlıyorlar. Testçi, test

kodunu yazan geliştiricilerle eş olmalıdır. Eğer Testçi hiç kod yazamıyorsa yine de geliştiricilerle eşli

programlama yapmalıdır. Eşli programlamayı yaparken Gözlemci rolünde olmalı ve kodlamayı

geliştirici yapmalıdır. İyi bir testçi iyi bir geliştiriciden farklı tipte testler yapabilmelidir. Böylece

birbirlerini tamamlayabilirler.

Eğer Takım TYG(Test Yönelimli Geliştirme) yapmıyorsa ya da Testçi’nin zamanını dolduracak kadar

test senaryosu yoksa Takımın Sprint Hedefine ulaşabilmesi için elinden ne yardım geliyorsa onu

yapmalıdır, tıpkı diğer takım üyeleri gibi. Eğer Testçi kodlama yapabiliyorsa ne mutlu. Eğer kodlama

yapamıyorsa o zaman içinde kodlama olmayan bütün işler önceden belirlenmelidir.

Takım, Sprint Planlama Toplantısı’nda kullanıcı hikayelerini daha küçük işlere bölerken kodlama

işlerine odaklanma eğilimindedir. Her neyse genelde içinde kodlama olmayan ve Sprint içinde

yapılması gereken birçok iş vardır. Sprint Planlama Toplantısı’nın ikinci bölümünde içinde kodlama

olmayan işleri belirlerseniz, Testçi, kod yazamasa ve test edecek bir şey olmasa bile Sprint Hedefi’ne

ulaşmak için oldukça yardımcı olabilir.

Sprint içinde yapılması gereken kodlama içermeyen işler:

- Test ortamının kurulması.

- Kullanıcı hikayelerinin netleştirilmesi.

- Operasyon ekibiyle teslim detaylarının konuşulması.

- Teslim dokümanlarının yazılması

- Takım dışındaki kişilerle iletişime geçilmesi(Örneğin ekran tasarım ekibi)

- Build script’lerinin iyileştirilmesi

- Kullanıcı hikayelerinin daha küçük parçalara bölünmesi

- Geliştiricilerden gelen önemli soruları belirlemesi ve cevaplaması

Öte yandan eğer Testçi darboğaza dönüşürse ne yaparız? Diyelim ki Sprint’in son günündeyiz ve

birçok kullanıcı hikayesi bitirildi ve Testçi’nin her şeyi test etmesi mümkün değil. Ne yaparız?

Takımdaki herkesi testçinin yardımcısı yapabiliriz. Hangi kullanıcı hikayelerinin testlerini kendisinin

yapması gerektiğine karar verir ve diğer testleri takıma yönlendirir. Çapraz fonksiyonel takım budur!

112

Evet, Testçi’nin takımda özel bir rolü vardır fakat diğer işleri de yapabilir ve takımın diğer üyeleri de

test yapabilirler.

Sprint’te Daha Az İş Yaparak Kaliteyi Artırma

Tekrar Sprint Planlama Toplantısı’na dönelim. Sprint’e çok fazla kullanıcı hikayesi sıkıştırmayın! Eğer

kalite probleminiz ya da uzun kabul testi döngüleriniz varsa Sprint içinde daha az şey geliştirin. Bu

otomatik olarak kalitenizi artıracak, kabul testleriniz daha kısa sürecek, son kullanıcı daha az hatayla

karşılaşacak ve uzun vadede daha yüksek bir üretkenlik elde edeceksiniz. Çünkü Takım bozulan eski

işleri düzeltmeye çalışmaktansa yeni işlere odaklanabilecek.

Daha az iş geliştirmek neredeyse her zaman daha ucuzdur. Fakat bunu stabil bir şekilde yapmak

gerekir.

Kabul Testi Aşaması, Sprint’in Bir Parçası mıdır?

Bu konuda oldukça bocalıyoruz. Bazı takımlarımız kabul testini Sprint’e dahil ediyor. Takımlarımızın

büyük çoğunluğuysa aşağıdaki iki nedenden dolayı Sprint’e dahil etmiyor:

- Sprint’in süresi belirlidir. Kabul testi aşamasının(kod düzeltilebilir ve yeniden teslim

yapılabilir) süresini önceden belirlemek oldukça zordur. Peki süreniz biter ve hala

düzeltmeniz gereken hatalar olursa ne olacak? Düzeltmeniz gereken bir hatayla üretim

ortamına mı çıkacaksınız? Gelecek Sprint’i mi bekleyeceksiniz? Birçok durumda iki senaryo da

kabul edilemez. Bu yüzden manuel kabul testi aşamasını Sprint’e dahil etmeyiz.

- Eğer aynı üründe çalışan birden fazla Scrum Takımı’nız varsa takımların ortak çalışmasının

sonunda manuel test tamamlanabilir. Eğer tüm takımlar Sprint içinde manuel kabul testi

yapsa bile üretim ortamına alınmadan önce test yapması için yine bir test takımına ihtiyacınız

olur.

Çok doğru söylemişim(Ara sıra kendimi tebrik edebilirim, değil mi?). Ayrıca takımdaki diğer

yetkinliklere de bakmanın güzel bir yoludur.

Bu çok doğru! Dünya’nın her yerindeki takımlarda bunu tekrar tekrar görüyorum.

113

Bu mükemmel bir çözüm değil fakat birçok durumda bizim için yeterli.

Sprint Döngüleri mi, Kabul Testi Döngüleri mi?

Mükemmel Scrum dünyasında kabul testi aşamasına ihtiyacınız olmaz. Çünkü takımınız her Sprint’ten

sonra üretime alınmaya hazır kodu geliştirir.

Tekrar söylüyorum. Kabul testlerini her Sprint yapmaya çalışın. Bunun için biraz çaba harcamanız

gerekecek fakat pişman olmayacaksınız. Bu konuda çok iyi bir seviyeye gelemeseniz dahi deneme çabanız bile çalışma şeklinizde birçok iyileştirme yapmanızı sağlayacaktır.

Bu yapılabilir! Her gün üretim ortamına teslim yapan bu dünyadan takımlar gördüm. Hatta bazen

günde birkaç defa yapanlar var. Bir Scrum eğitmeni “her Sprint sonunda tamamen test edilmiş

teslim edilebilir ürün parçacığı geliştirmiş olmalısınız” dediğinde tepkileri; “Haaa, neden o kadar bekleyelim ki?” olur.

Yani mükemmel Scrum dünyasına ihtiyacınız yok. Kollarınızı sıvayın ve her Sprint teslim edilebilir

kod geliştirmekten neyi sizin alıkoyduğunu görün ve problemleri bir bir çözüml eyin. Elbette

çalıştığınız ortama bağlı olarak bu kolay ya da zor olabilir fakat yine de denemeye değer. Teslim döngünüzü belirleyin(aylık, yıllık) ve yavaş yavaş fakat sürekli olarak kısaltmaya çalışın.

114

Burada daha gerçekçi bir resim:

Sprint 1’den sonra hatalı 1.0.0 versiyonu teslim edildi. Sprint 2 sırasında hata raporları gelmeye

başladı ve Takım zamanının çoğunu hataları düzeltmeye harcadı. Ayrıca Takım Sprint ortasında 1.0.1

versiyonunu teslim etmeye zorlandı. Sprint 2’nin sonunda yeni özelliklerin olduğu 1.1.0 versiyonunu

teslim ettiler. Tabi ki bu versiyonda daha da çok hata vardır. Çünkü Sprint 2’de, Sprint 1’e oranla

kalite için daha az zaman harcamışlardır.

Sprint 2’deki kırmızı çizgiler kaosu simgeler.

Çok güzel değil! Kötü olan şey kabul testi için bir takımınız olsa bile sorun devam eder. Tek fark hata

raporlarının çoğu kızgın kullanıcılar yerine test takımından gelir. İş birimi tarafından bu oldukça büyük

bir farktır fakat geliştiriciler açısından neredeyse fark yoktur. Sadece test takımı son kullanıcılardan

daha az agresiftir.

Bu probleme herhangi basit bir çözüm bulamadık. Gerçi birçok farklı model denedik.

115

Her şeyden önce Scrum Takımı’nın geliştirdiği kodun kalitesini en yükseğe çekin. Sprint içinde hataları

erkenden bulmanın ve çözmenin maliyeti Sprint sonrasında hataları bulma ve çözme maliyetiyle

karşılaştırıldığında oldukça düşüktür.

Hataların sayısını en aza indirsek bile Sprint sonrasında gelecek hatalar olacaktır. Bununla nasıl başa

çıkacağız?

Yaklaşım 1: “Eski Kullanıcı Hikayelerini Üretim Ortamına Almadan

Yeni Kullanıcı Hikayelerini Geliştirmeye Başlamayın”

Kulağa hoş geliyor, değil mi? Ayrıca sıcak bir meltem hissettiniz mi?

Bu yaklaşımı benimsemeye birkaç sefer yaklaştık ve nasıl yapabileceğimize dair süslü modeller çizdik.

Fakat olumsuz yönünü gördüğümüzde fikrimizi değiştirdik. Sprint’ler arasında süresi belli olmayan

teslim periyotlarımız vardı ve bu periyot içinde teslimi yapacak kadar sadece test yapıp, hataları

düzeltiyorduk.

Sprint’ler arasında süresi belirli olmayan teslim periyotları fikrinden hoşlanmadık. Çünkü Sprint kalp

atış ritmini bozuyordu. Artık “her üç haftada bir yeni Sprint’e başlıyoruz” diyemezdik. Ayrıca bu

yaklaşım problemi tamamıyla çözmüyordu. Teslim periyodu olsa bile zaman zaman acil olarak gelen

hatalar oluyordu ve bunları çözmeye hazır olmak zorundaydık.

Aslında bu doğru. Sürekli teslim yapsanız bile acil olarak gelen hatalarla başa çıkmak için bir yola

ihtiyacınız vardır. Hiçbir takım acil olarak gelen hataları olmayacak kadar iyi değildir. Bu durumla başa

çıkmanın en iyi yolu Sprint içinde biraz boşluk bırakmaktır.

Bitti Tanımı’nızda “üretim ortamında” maddesi varsa, bu durumda sıradaki Sprint’e hemen

başlayabilirsiniz. Çünkü son Sprint’in kodu hali hazırda üretim ortamında. Sprint sırasında sürekli olarak üretim ortamına teslimler yapıldı. Biraz uç bir nokta fakat yapılabilir.

Evet. Mükemmel!

116

Yaklaşım 2: “Yeni Kullanıcı Hikayeleri Geliştirilebilir Fakat Eski

Kullanıcı Hikayeleriyle Karşılaştırılıp Öncelikleri Belirlenmelidir”

Tercih ettiğimiz yaklaşım bu, en azından şimdilik:

Bir Sprint bittiğinde sıradakine başlarız. Sıradaki Sprint’te bir önceki Sprint’te oluşan hataları

düzeltmek için daha fazla zaman ayrılmasını bekleriz. Eğer bir önceki Sprint’te oluşan hataları çözmek

için gelecek Sprint tehlikeye girerse bunun neden kaynaklandığını ve kaliteyi nasıl

iyileştirebileceğimizi değerlendiririz.

Bir önceki Sprint’ten kalan hataları çözmek için ayrılan süre kademeli olarak azaldı. Ayrıca hatalar

oluştuğunda tüm takımın ilgilenmesi yerine sadece birkaç kişiyle bile çözülebilecek kadar bilgimizi

artırdık. Böyle bir hata geldiğinde tüm takımın odağı dağılmamış oluyor. Şimdilerde biraz daha kabul

edilebilir bir seviyedeyiz.

Sprint Planlama Toplatısı sırasında odak çarpanını düşürürüz böylece bir önceki Sprint’ten kalan

hataları çözebilmek için zamanımız olur. Zamanla takım bu tahmini yapmada oldukça iyi bir seviyeye

geldi. Takım hızı metriği çok yardımcı oldu.

Kötü Yaklaşım: “Yeni Kullanıcı Hikayeleri Geliştirmeye Odaklanma”

Bunun anlamı “eski kullanıcı hikayelerini üretim ortamına almaktansa yeni kullanıcı hikayeleri

geliştirmeye odaklanmaktır”. Kim bunu yapmak ister? Buna rağmen başlangıçta bu hatayı çok yaptık

ve birçok şirketin bu hatayı yaptığına eminim. Bu stresle alakalı bir hastalıktır. Birçok müdür bu

hastalığı anlamaz bile. Bütün kodlama bittiğinde bile üretim ortamına teslimden çok uzaksınızdır.

Ya da sadece dünün havası tekniğini kullanın. Bir önceki Sprint’te bitirdiğiniz kullanıcı

hikayelerinin toplamı kadar iş alın. Son üç Sprint’inizin ortalaması kadar iş çekmekte iyi bir

pratiktir. Böylece dikkati dağıtan şeyler ve üretim ortamından gelen hatalar için gerekli boş zaman

otomatik olarak belirlenmiş olacaktır. Otomatik olarak kapasiteye göre iş miktarını sınırlamış ve

sonuç olarak daha hızlı hareket etmiş olacaksınız. Sprint’lerinize fazla iş almanın kötü bir fikir olduğunu anlamak için Yalınlık ya da kuyruk teorisi üzerine herhangi bir kitabı okuyabilirsiniz.

117

Sonra müdür(ya da Ürün Sahibi), Takıma yeni kullanıcı hikayelerini sorar, bu sırada eski kullanıcı

hikayeleri, neredeyse üretim ortamına teslime hazır kullanıcı hikayeleri gittikçe ağırlaşır ve ağırlaşır,

her şeyi yavaşlatırlar.

Zincirinizdeki En Zayıf Halkayı Geçmeye Çalışmayın

Diyelim ki kabul testi zincirinizdeki en zayıf halka, az sayıda testçiniz var ya da düşük kod kalitesinden

dolayı kabul testi aşaması çok uzun sürüyor.

Diyelim ki kabul testi takımınız haftada üç işlevselliği test edebiliyor(hafta başına düşen işlevselliği

metrik olarak kullanmıyoruz, sadece burada örnek veriyorum). Ve diyelim ki geliştiricileriniz haftada

altı işlevsellik geliştirebiliyorlar.

Müdür ya da Ürün Sahibi(hatta Geliştirme Takım’ı) için haftada altı işlevsellik geliştirecek şekilde plan

yapmak cazip gelebilir.

Yapmayın! Gerçek öyle ya da böyle karşınıza çıkacak ve canınızı yakacaktır.

Bunun yerine haftada üç işlevsellik geliştirecek şekilde planlama yapın ve kalan zamanı test

darboğazını hafifletmek için harcayın. Örneğin:

- Birkaç geliştirici test yapmaya başlasın(of, bu yüzden sizi çok seveceklerdir).

- Test yapmayı kolaylaştıracak araçları ve script’leri geliştirin.

- Otomatik test yapan kodlar geliştirin.

- Sprint uzunluğunu artırın ve kabul testi aşamasını Sprint’e dahil edin.

- Bazı Sprint’leri test Sprint’i olarak belirleyin ve tüm takım kabul testi için çalışsın.

- Daha fazla testçiyi işe alın(bunun anlamı birkaç yazılımcının gönderilmesi olsa bile).

Sonuncu hariç bütün çözümleri denedik. Uzun vadede en iyi seçenekler ikinci ve üçüncüdür.

Bu tuzağa düşen şirketleri gördükçe şaşırıyorum. Tek yapmanız gereken aynı anda geliştirdiğiniz

işlevsellik, proje sayısını limitlemektir. Bunu yaparak yedi kat hızlanan şirketler gördüm. Şunu

düşünün aynı miktarda çalışıyorsunuz fakat yedi kat hızlısınız. Daha fazla çalışmadınız ve birilerini

işe almadınız. Ayrıca daha kaliteli iş çıkarmaya başladınız. Çünkü geribildirim döngünüz kısaldı. Delice fakat gerçek!

118

Retrospektifler takımdaki en zayıf halkayı belirlemek için iyi bir fırsattır.

Gerçeğe Dönüş

Muhtemelen tüm Scrum Takımları’mızda testçiler olduğu, her bir ürün için büyük bir kabul testi

takımımız olduğu ve her Sprint’ten sonra üretim ortamına teslim yaptığımız izlenimini yarattım.

Yapmıyoruz!

Bazen bunları yapabiliyoruz ve pozitif etkilerini görüyoruz. Fakat kabul edilebilir kalite güvence

sürecinden hala uzaktayız ve öğrenmemiz gereken birçok şey var.

Kabul testi aşaması Sprint’e dahil edilirse bu yaklaşım kendi kendini uyarlamaya dönüşür. Deneyin, Bitti Tanımınıza kabul testini dahil edin ve zamanla neler olacağını görün.

Gerçekten öğrenmemiz gereken çok şey vardı! :)

119

Bölüm

Onbeş

Birden Fazla Scrum Takımı’yla Nasıl Çalışıyoruz?

Aynı ürün üzerinde çalışan birden fazla Scrum Takımı olduğunda işler daha da zorlaşıyor. Bu problem

evrensel ve Scrum’la bir ilgisi yok. Daha fazla geliştirici = Daha fazla karışıklık

Bu konu üzerine deneyler yaptık. En büyük deneyimizde bir ürün üzerinde çalışan 40 kişi vardı.

Önemli sorular:

- Kaç Scrum Takımı oluşturulacak?

- Kişiler hangi takımlarda yer alacak?

Kaç Scrum Takımı oluşturulacak?

Eğer birden fazla Scrum Takımı’nın aynı ürün üzerinde çalışması zorsa neden zahmet edip bunu

yapıyoruz? Neden herkesi aynı Scrum Takımı’na koymuyoruz?

En büyük Scrum Takımımızda 11 kişi vardı. Çalıştı mı, evet çalıştı fakat çok iyi değil. Günlük Scrum

Toplantıları 15 dakikayı aştı. Bir takım üyesi başka bir takım üyesinin ne yaptığını bilmiyordu bu

nedenle kafa karışıklığı yaşanıyordu. Scrum Master, takım üyelerini Sprint Hedefi’ne yönlendirmekte

ve belirlenen engelleri kaldırmakta zorlanıyordu.

Bu kitabı yazdığımdan beri bir kurumda Çevikliğin yaygınlaştırılması konusunda çok fazla çalıştım.

Detaylı örnekler için Siperden Yalınlık kitabına göz atabilirsiniz. Şekil olarak bu kitaba oldukça

benziyor. 60 kişinin çalıştığı bir devlet projesinde Scrum, Kanban ve XP karışımının nasıl

kullanıldığını anlatıyor.

http://www.yilmazcihan.com/siperden-yalinlik-kanban-ile-buyuk-olcekli-projelerin-yonetimi/

Ve elbette takımlar birbirinden nasıl haberdar olacak.

120

Alternatif iki takıma bölünmektir. Peki bu iyi mi? Her zaman değil.

Eğer takım tecrübeliyse ve Scrum’ı seviyorsa yol haritasını ikiye bölmenin mantıklı bir yolu vardır. Yol

haritası ikiye bölündükten sonra aynı kaynak kodda birleşmemelidir. Böyle olursa ikiye böl me iyi bir

fikir olabilir. Yoksa büyük bir takım olarak kalmak, büyük takım olmanın dezavantajlarına rağmen

daha iyidir.

Deneyimlerime göre büyük birkaç takım olması, birbirinin ayağına basan birçok küçük takım

olmasından daha iyidir. Birbirlerinin ayaklarına basmayacaklarsa küçük takımlar oluşturun.

Sanal Takımlar

Büyük fakat az takım, küçük fakat fazla takım konusunda doğru ya da yanlış yaptığınızı nasıl

bileceksiniz?

Eğer gözlerinizi ve kulaklarınızı açarsanız sanal takımlar oluştuğunu fark edeceksiniz.

Örnek 1: Büyük bir takım oluşturmayı seçtiniz. Sprint içinde kim kiminle konuşuyor diye

gözlemlediğinizde takımın kendiliğinden iki parçaya bölündüğünü fark edeceksiniz.

Örnek 2: Üç küçük takım oluşturabilirsiniz. Fakat Sprint içinde kimin kiminle konuştuğunu

gözlemlemeye başladığınızda Takım 1 ve Takım 2 sürekli olarak birbiriyle konuşurken Takım 3

bağımsız olarak çalışmaktadır.

121

Bunun anlamı nedir? Takımları oluşturma stratejiniz yanlış mıydı? Eğer sanal takımlar kalıcıysa evet,

yanlıştı. Eğer sanal takımlar geçiciyse hayır, yanlış değildi.

Örnek 1’e tekrar bakın. Eğer sanal alt takımlar arada bir değişme eğilimindeyse(eğer kişiler takımlar

arasında gidip geliyorsa) o zaman büyük ihtimalle doğru kararı verdiniz. Eğer iki sanal takım arasında

tüm Sprint boyunca insanlar gidip gelmiyorsa gelecek Sprint’lerde takımı ikiye bölmek isteyebilirsiniz.

Şimdi Örnek 2’ye tekrar bakın. Eğer Takım 1’in ve Takım 2’nin üyeleri Sprint içinde sürekli iletişimde

bulunuyorsa, Takım 1 ve Takım 2’yi tek Scrum Takımı’nda birleştirmeyi düşünebilirsiniz. Eğer Takım 1

ve Takım 2 Sprint’in ilk yarısı birbirleriyle çok konuşuyorsa ve daha sonra Takım 1 ve Takım 3 Sprint’in

ikinci yarısında konuşmaya başlıyorsa o zaman üç takımı da bir Scrum Takımı’nda birleştirmeyi

düşünebilirsiniz ya da üç takım olarak bırakabilirsiniz. Sprint Retrospektif Toplantısı’nda bu konuyu

dile getirebilir ve takımların kendileri için karar vermesine izin verebilirsiniz.

Takımların belirlenmesi Scrum’ın en zor bölümlerinden biridir. Çok derin düşünmeyin ya da optimum

seviyeyi bulmak için çok uğraşmayın. Deney yapın, sanal takımları izleyin ve Sprint Retrospektif’te bu

konuları konuşmak için zaman ayırın. Er ya da geç özel durumunuz için çözümü bulacaksınız. Önemli

olan şey takımların rahat olması ve çok fazla birbirlerinin ayaklarına basmamalarıdır.

Gittikçe popülerliği artan yaklaşım gerekli oldukça takımların dinamik olarak kendi kendilerini

şekillendirmesidir. Ben bu modele “süper takım” ya da “dinamik alt takımlar” diyorum. Yakın

oturan, birbirini iyi tanıyan ve aynı ürün üzerinde çalışan 12-16 kişi olduğunda bu yaklaşım

oldukça başarılıdır. Ortak bir Ürün İş Listesi verin ve her bir kullanıcı hikayesi için küçük

kümeleriniz olsun. Pat, Tom ve ben A kullanıcı hikayesi üzerine çalışacağız. Kullanıcı hikayeleri

bittikçe yeni gruplar oluşturun. Pratikte bu yaklaşımı kullanabilmek için biraz basitleştirmek

gerekiyor. Büyük bir takım istemiyor ve küçük takımlara bölmek için kalıcı bir yol bulamadıysanız bu teknik mükemmeldir.

122

İdeal Takım Büyüklüğü

Okuduğum kitapların birçoğu ideal takım büyüklüğünün 5-9 arasında olduğunu iddia ediyor.

Şimdiye kadar gördüklerimle sadece katılabilirim, belki ben 3-8 arasında olduğunu söyleyebilirim.

Diyelim ki 10 kişiden oluşan bir Scrum Takımınız var. Takımın en zayıf iki üyesini çıkarmayı

düşünebilirsiniz. Oppps, gerçekten bunu söyledim mi?

Diyelim ki iki farklı ürününüz var, iki farklı üründe çalışan üçer kişilik iki takım var ve bu takımlar yavaş

ilerliyorlar. Bu iki takımı birleştirmek ve iki ürünün sorumluluğunu 6 kişilik takımda paylaştırmak iyi

bir fikir olabilir. Bu durumda Ürün Sahipleri’nden birini gönderebilirsiniz(ya da danışman rolü

verebilirsiniz, vb).

Diyelim ki 12 kişiden oluşan tek Scrum Takımı’nız var. Kaynak kodunuz o kadar kötü durumda ki iki

farklı takım kodunuz üzerinde bağımsız çalışamaz. Kaynak kodunuzu düzeltmek için ciddi efor

harcayın(yeni işlevsellikler geliştirmek yerine) ta ki iki farklı takım çalışabilecek duruma gelene kadar

kodunuzu düzeltin. Bu yatırım oldukça çabuk geri dönecektir.

Bu cümleden sonra nasıl kurtuldum bilmiyorum? :)

Her neyse büyük takımların bazı üyeleri tatildeyken daha hızlı ilerlediğini fark ettim. Fakat genel

olarak tatilde olanlar zayıf üyeler olduğu için değil sadece takım büyüklüğü daha yönetilebilir bir seviyeye geldiği, iletişim ve kargaşa azaldığı içindir.

Bu vurgulamaya değer. Eğer doğru takım yapısını bulmak zor olduysa genellikle gerçek suçlu

sistem mimarisidir. İyi mimari takımların hızlı ve bağımsız hareket etmesine izin verir, kötü

mimari takımların birbirlerinin ayaklarına basmalarına ve bağımlılıklarda boğulmalarına neden

olur. Yani mimarinizi ve takım yapınızı sürekli olarak sorgulamalı ve geliştirmelisiniz.

123

Sprint’ler Senkronize mi, Değil mi?

Diyelim ki aynı ürün üzerinde çalışan 3 takımınız var. Sprint’leri senkronize olmalı mı? Sprint’leri aynı

anda başlamalı ve bitmeli mi? Yoksa farklı ritimde Sprint’leri olabilir mi?

İlk yaklaşımımız farklı ritimlere sahip Sprint’lerdi.

Mantıklı geldi. Zaman içinde herhangi bir anda bitecek olan ve yenisi başlayacak olan bir Sprint vardı.

Ürün Sahipleri’nin iş yükü zamanla eşit seviyeye gelecekti. Sürekli akan teslimler olacaktı. Her hafta

demolar olacaktı.

Evet, biliyorum, fakat o zaman gerçekten mantıklı gelmişti!

Bunu yapmaya başladığımız zaman Ken Schwaber’le konuşma şansı elde ettim. Bunun kötü bir fikir

olduğunu söyledi. Sprint’leri senkronize koşmak çok daha iyi olabilirdi. Tam söylediklerini

hatırlamıyorum fakat biraz tartışmadan sonra ikna olmuştum.

O zamandan beri kullandığımız çözüm bu ve asla pişman olmadık. Farklı ritimlere sahip stratejinin

başarısız olup olmayacağını asla bilemeyeceğim. Fakat başarısız olacağını düşünüyorum. Senkronize

Sprint’lerin avantajı:

- Takımları yeniden düzenlemek için doğal bir zaman var. Farklı ritimlere sahip Sprint’lerde

Sprint ortasında bir takımı bölmeden bunu yapmanın bir yolu yok.

- Bütün takımlar aynı hedefe yönelik çalışabilirler. Sprint Planlama Toplantılarını beraber

yapabilirler. Böylece takımlar arasında daha iyi bir iş birliği oluşur.

- Yönetimsel yük daha azdır. Daha az Sprint Planlama Toplantısı, Sprint demosu ve teslim.

124

Takım Lideri Rolü Neden Var?

Diyelim ki bir ürünümüz ve üç takımımız var.

P ile işaretlenen kırmızı adam Ürün Sahibi. S ile işaretlenen siyah adamlar Scrum Master. Geriye

kalanlar takım üyeleri.

Bu yapıda kimin hangi takımda olacağına kim karar veriyor? Ürün Sahibi mi? Üç Scrum Master

beraber mi? Yoksa herkes kendi takımını kendi mi seçiyor? Peki ya herkes Takım 1’de olmak

isterse(Takım 1’in Scrum Master’ı çok güzel olduğu için)?

Peki ya sonraları kod üzerinde aynı anda ikiden fazla takımın çalışamayacağı ortaya çıkarsa? 18

kişiden oluşan bu topluluğu 9 kişiden iki takıma bölmemiz gerekirse. Bunun anlamı iki Scrum Master

demektir. Peki şu anki üç Scrum Master’dan hangisi Scrum Master’lıktan vazgeçecek.

Birçok şirkette bu oldukça hassas bir konudur.

Her takımın kendi Sprint uzunluklarını belirlemesi kararını alana dek Spotify’da senkronize

Sprint’leri kullandık. Bazı takımlar Scrum yerine Kanban kullanıyor. Takımlar arasında çok fazla

bağımlılık olduğunda senkronizasyon için günlük Scrum’ların Scrum’ı şeklinde bir toplantı ve

entegre olmuş ürünün haftalık demosunu yapıyoruz. Bunu yaparken takımların kendi

ritimlerinden bağımsız bir şekilde yapıyoruz. Gerçi hangi modelin daha iyi olduğunu söyleyemem.

İçinde bulunduğunuz duruma bağlı.

Kişilerin hangi takımda yer alacağını Ürün Sahibi’nin belirlemesine izin vermek çekicidir. Fakat

gerçekte bu Ürün Sahibi’nin yapacağı bir şey değildir. Ürün Sahibi iş konusunun uzmanıdır ve

Takıma hangi yönde ilerlemesi gerektiğini söyleyen kişidir. Ürün Sahibi bu detaylarla ilgilenmek zorunda bırakılmamalıdır. O zaman bu işi kim yapacak? Okumaya devam edin…

125

Bu konuyu Takım Lideri rolünü belirleyerek aştık. Bu role “Scrum’ların Scrum Master’ı” ya da

“patron” ya da “Ana Scrum Master” diyebilirsiniz. Hiçbir takımı yönetmek zorunda değildir. Fakat

kimin Scrum Master olacağından ve kişilerin hangi takımlarda yer alacağı gibi konulardan

sorumludur.

Bu rol için iyi bir isim bulmakta zorlandık. “Takım Lideri” bulabildiğimiz en az saçma isimdi.

Bu çözüm bizim için iyi çalıştı ve öneriyorum. Rolün adına ne dediğiniz önemli değil.

Takımları Nasıl Belirleriz?

Aynı üründe birden fazla Scrum Takımı olacağı zaman kişilerin hangi takımlarda yer alacağını

belirlerken kullandığımız iki strateji vardır:

Belirli biri takımlarda kimin görev alacağını belirler. Yukarıda bahsettiğim gibi takım lideri, Ürün

Sahibi ya da müdür(iyi bir karar verecek kadar ürüne ve takımlara dahil olduysa).

Takımların kendi kendilerine karar vermesine izin veririz.

Üçünü de deneyimledik. Üç mü? Strateji 1, Strateji 2 ve ikisinin karışımı.

İkisinin karışımının en iyi yol olduğunu öğrendik.

Sprint Planlama Toplantısı’ndan önce takım lideri kimin hangi takımda yer alacağını belirlemek için

Ürün Sahibi ve Scrum Master’larla bir toplantı yapar. Son Sprint’i konuşuruz ve takımlarda bir

değişiklik olup olmayacağına karar veririz. Belki iki takımı birleştiririz ya da bir takımdan diğerine bazı

kişilerin geçmesini isteyebiliriz. Bir şeye karar veririz ve teklif edilen takım yapısı yazarız. Daha sonra

bu teklifi Sprint Planlama Toplantısı’na getiririz.

Birçok şirkette bu işten kaynak yöneticisinin sorumlu olduğunu ve takım liderine ihtiyaç

olmadığını gördüm. Ayrıca takım lideri kafa karıştıran bir isim ve sadece bir takım varmış gibi

düşündürüyor. Her neyse en iyi müdürler takımlarının kendi kendilerini yönetebilmeleri için

farklı şekilde yardım ederler ve yukarıdan aşağıya görevleri atamazlar.

Deneylerle geçen onca yıldan sonra sadece katılıyorum.

126

Sprint Planlama Toplantısı’nda yaptığımız ilk şey Ürün İş Listesi’nde en üstte bulunan maddeler

üzerinden geçmektir. Daha sonra Takım Lideri şöyle bir şey söyler: “Gelecek Sprint’in takımlarını

aşağıdaki gibi düşünüyoruz”.

“Gördüğünüz gibi dört takımdan üç takıma düşmüş oluyoruz. Her takımın üyelerini l isteledik. Lütfen

bir araya gelin ve Scrum Duvarı’nda kendi alanınızı belirleyin.”

(İnsanlar odada dolaşırken Takım Lideri bekler bir süre sonra Scrum Duvarı’nın yanında üç grup

oluşmuş olur)

“Şu an belirlediğimiz takımlar sadece bir ön hazırlıktır! Zaman kazanmak için sadece bir başlangıç

noktası. Sprint Planlama Toplantısı’nda ilerledikçe bir başka takıma geçmekte, takımınızı ikiye

bölmekte veya başka bir takımla birleşmekte özgürsünüz. Ürün Sahibi’nin önceliklerini temel alarak

içgüdünüze güvenin.”

Bizim bulduğumuz en iyi çalışan yol. Başlangıçta bir dereceye kadar merkezi kontrol daha sonraysa

merkezi olmayan bir iyileştirme.

Uzmanlık Takımları mı?

Diyelim ki kullandığınız teknoloji üç ana alanı içeriyor:

Çok iyi bir model! Bunu yapmanın birçok farklı yolu vardır. Sprint Planlama’yla beraber yapmak

sadece bir yoludur ve her zaman en iyi yol olmayabilir. Bugünlerde takımları yeniden organize

etme atölyelerini Sprint Planlama Toplantısı’ndan ayrı yapıyorum. Böylece Sprint Planlama

Toplantısı’nın odağı dağılmıyor. Böylece Sprint’i planlarken takım yapımız ve Ürün İş Listemiz

daha stabil oluyor. Büyük projelerde Sprint Planlama Toplantıları’nı aynı anda büyük bir oda da yapmak yararlıdır. Bazen bir bağımlılık birinin takım değiştirmesiyle çözülebilir.

127

Ve diyelim ki bu ürün için çalışan 15 kişi var. Bu nedenle tek bir Scrum Takımı oluşturmak

istemiyorsunuz. Hangi takımları oluşturursunuz?

Yaklaşım 1: Alanlarına Göre Uzman Takımlar

Bir yaklaşım alanlarına göre uzman takımlar oluşturmaktır. Örneğin client takımı, server takımı ve

veritabanı takımı.

Burası başladığımız yer. Bizim için çalışan bir yöntem değildi, özellikle kullanıcı hikayeleri birden fazla

alanı ilgilendirdiğinde.

Örneğin “kullanıcılar birbirine mesaj gönderebilsin” şeklinde bir kullanıcı hikayemiz var. Bu

mesajlaşma işlevselliği kullanıcı ara yüzünün güncellenmesini, server tarafına bu işin mantığının

eklenmesini ve veri tabanına bazı tablolar eklenmesini içerir.

128

Bunun anlamı bu kullanıcı hikayesini bitirebilmek için üç takımın iş birliği içinde olması gerektiğidir.

İyi bir pratik değil.

Yaklaşım 2: Çapraz Takımlar

İkinci yaklaşım çapraz takımlar oluşturmaktır. Çapraz takımlar herhangi bir uzmanlık alanına bağımlı

değildirler.

Eğer kullanıcı hikayelerinizi geliştirebilmek için birden fazla teknolojiye ihtiyaç duyuyorsanız bu

şekilde bir bölünme stratejisi daha çok işinize yarayacaktır. Her takım, client, server ve veritabanı

parçalarını geliştirebilir. Böylece takımlar birbirinden bağımsız çalışabilir ki bu iyi bir şeydir.

Scrum’a başladığımızda yaptığımız ilk şeylerden biriydi; uzmanlık takımlarını bölüp(yaklaşım 1) çapraz

takımlar(yaklaşım 2) oluşturmak. “Bu işi bitiremiyoruz çünkü server takımının kendi tarafına düşen işi

yapmalarını bekliyoruz” durumlarını azalttı.

Birçok şirkette yaşanan ortak bir problem!

129

Uzmanlık takımları da oluşturabiliriz fakat bunu yapmamız için çok büyük bir ihtiyaç olmalıdır.

Sprint’ler Arası Takımlar Yeniden Ayarlanmalı mı, Ayarlanmamalı

mı?

Her Sprint ne tip kullanıcı hikayelerinin öncelikli olduğuna göre birbirinden farklıdır. Sonuç olarak

belki takım da değişmelidir.

Aslında neredeyse her Sprint kendimizi şöyle bir şey derken buluyoruz: “Bu Sprint gerçekten normal

bir Sprint değildi çünkü ……….”. Bir süre sonra normal Sprint kavramından vazgeçtik. Normal bir aile,

normal bir hayat olmadığı gibi normal bir Sprint de yoktur.

Bir Sprint sadece client tarafından yazılım geliştiriciler olması iyi bir fikir olabilir. Bir sonraki Sprint

uzmanlık takımlarından üyelerin olduğu ve client tarafındaki yazılım geliştiricilerin bu ikisi arasında

Neredeyse çalıştığım tüm şirketlerde aynı hikaye! Uzmanlık takımlarında işlevsellik takımlarına doğru yeniden yapılandırma yıkıcı olabilir fakat faydası çok büyüktür!

Bazen uzmanlık takımlar mantıklı gelebilir, hatta uzun vadede bile. Fakat bu durum istisna

olmalıdır. Takım için iyi bir test sorusu: “Müşterimiz kimdir ve müşterimizin ihtiyaçlarını diğer

takımlara bağımlı olmadan karşılayabiliyor muyuz?” İşlevsellik takımları bu testi geçerken

uzmanlık takımları geçemeyecektir. Organizasyon içinde kullanılacak araçları ve platformları

geliştiren takımlar buna istisna olabilir. Bu takımlar, organizasyonda bulunan takımlara hizmet

sağlarlar, bu nedenle diğer takımlara müşterileri gibi davranmalılardır. Büyük organizasyonlar

genelde dışarı hizmet veren takımları işlevsellik takımı ve içeri hizmet veren takımları uzmanlık

takımlarından oluşan karışık bir yapıya bürünürler. Gerçi çözüm için sihirli bir değnek yok, bu nedenle deney yapmaya devam edin!

130

bölüştürüldüğü bir yapıya bürünmek de iyi bir fikir olabilir.

Scrum’ın önemli yapı taşlarından biri takım uyumudur. Örneğin bir takım birkaç Sprint bir arada

çalıştı mı arada sıkı bağlar oluşur. Takım, grup akışını başarmayı öğrenir ve inanılmaz bir verimlilik

seviyesine ulaşır. Fakat buraya erişmek birkaç Sprint alacaktır. Eğer takımların üyelerini değiştirmeye

devam ederseniz, uyumlu takıma sahip olamazsınız.

Bu nedenle takım üyelerini her Sprint’te değiştirmeyi düşünüyorsanız sonuçlarını iyi düşünün. Bu

uzun vadeli bir değişiklik mi, kısa vadeli bir değişiklik mi? Eğer kısa vadeli bir değişiklikse, bu

değişikliği hiç yapmamayı düşünün. Eğer uzun vadeli bir değişiklikse yapabilirsiniz.

Büyük bir takımla ilk defa Scrum yapıyorsanız yukarıdaki kural için bu bir istisnadır. Bu durumda

herkesin rahat olacağı bir yapı bulana kadar deney yapmaya devam edin. İlk birkaç seferde hatalı

yapılar kurmanın problem olmadığını herkesin anladığından emin olun. Önemli olan sürekli

geliştirmektir.

Yarı Zamanlı Takım Üyeleri

Ancak Scrum kitabının söylediğini onaylayabilirim. Scrum Takımı’nda yarı zamanlı üyeler olması iyi bir

fikir değildir.

Diyelim ki Joe’yu Scrum Takımı’nıza yarı zamanlı alacaksınız. Önce dikkatlice düşünün. Joe’ya

gerçekten takımınızda ihtiyacınız var mı? Joe’yu tam zamanlı alamayacağınızdan emin misiniz?

Joe’nun yapması gereken diğer işler neler? Başka biri Joe’nun diğer işlerini yapamaz mı, diğer işler

konusunda Joe pasif ve destekleyici bir rol üstlenemez mi? Bir sonraki Sprint’ten sonra Joe takımınıza

tam zamanlı olarak katılamaz mı, böylece bu zaman içinde sorumluluklarını bir başkasına aktaramaz

mı?

Kabul görmüş bir kural: Birkaç Sprint’ten sonra takım yapınız oldukça stabil olmalıdır. Herhangi

bir takımın yapısı en az üç ay boyunca değiştirilmemelidir. Takıma bir üye eklenmemeli ya da

takımdan bir üye çıkarılmamalıdır. Eğer takım daha sık bir şekilde değişiyorsa Scrum’ın

hedeflediği hiper verimli bir duruma ulaşılamayacaktır. Takım dışından empoze edilen

değişiklikler, Takım içinden başlatılan değişikliklere daha yıkıcıdır. Yani eğer siz bir müdürseniz

günaha girmeden önce daha fazla direnç göstermeye çalışın. İnsanların odaklanmasına izin verin,

takımın stabilleşmesi için yardımcı olun fakat takım üyeleri değişim için bir ihtiyaç gördüğünde takımlarını değiştirmelerine izin verin. Muhtemelen sonuçlar sizi büyüleyecektir!

...deneyimlerinde gösterdiği gibi. Genelde berbat bir durumdur!

131

Bazen sadece başka yol yoktur! Bazen umutsuz bir şekilde Joe’ya ihtiyacınız vardır çünkü binadaki tek

DBA, Joe’dur. Diğer takımlar da en az sizin kadar Joe’ya ihtiyaç duyuyordur. Bu nedenle takımınızda

hiçbir zaman “tam zamanlı” olarak çalışamayacaktır ve şirket bir başka DBA işe alamıyordur. Peki. Bu

durum Joe’yu yarı zamanlı takıma almak için geçerli bir durumdur. Bu arada bu durum bizim başımıza

gerçekten geldi. Takımınıza biri yarı zamanlı katılacağı zaman yukarıdaki değerlendirmeyi

yaptığınızdan emin olun!

Takımımda yarı zamanlı çalışan sekiz kişi olmasındansa tam zamanlı çalışan üç kişi olmasını tercih

ederim.

Eğer zamanını birden fazla takıma bölecek bir takım üyeniz varsa yukarıda bahsettiğim DBA gibi,

birincil takımını belirlemek iyi bir fikir olabilir. Ona en çok ihtiyaç duyan takımı belirleyin ve bu takımı,

onun “ana takımı” yapın. Yan takımlardan herhangi birine gitmediğinde kendi takımının Günlük

Scrum, Sprint Planlama, Sprint Değerlendirme ve Sprint Retrospektif Toplantısı’na katılacaktır.

Scrum’ların Scrum’ını Nasıl Yapıyoruz?

Scrum’ların Scrum’ı tüm Scrum Master’ların toplandığı ve konuştuğu düzenli bir toplantıdır.

Dört ürünümüz vardı, ürünlerden üçü birer Scrum Takımı tarafından geliştiriliyordu. Son ürünse

birkaç Scrum Takım’dan oluşan 25 kişi tarafından geliştiriliyordu. Aşağıdaki gibi:

Kabul görmüş bir genel kural: Tam zamanlının anlamı zamanının en az %90’ınını takımla

geçirmektir. Yarı zamanlı demek zamanının %50-90 aralığında takımla geçirmektir. (Bu benim ana

takımım fakat yapmam gereken başka işler de var.) Zamanının %50’den daha azını takımla

geçiren biri takım üyesi değildir.(Zaman zaman size destek verebilirim fakat takımınızın bir üyesi

değilim ve bana her zaman güvenemezsiniz). Eğer takımda yarı zamanlı çalışan sadece bir kişi

varsa o zaman çok endişelenmeyin. Eğer birden fazla yarı zamanlı çalışan varsa o zaman yeniden

organize olmayı ve üzerinde çalışılan iş sayısını azaltmayı düşünebilirsiniz. Böylece bazı yarı

zamanlı çalışanlar tam zamanlı çalışan olabilirler. Çok görevlilik, verimliliği, motivasyonu ve kaliteyi öldüren bir canavardır. Bu nedenle en az seviyede tutmaya çalışın!

132

Bunun anlamı iki farklı seviyede Scrum’ların Scrum’ı yapmamızdır. Ürün seviyesinde Scrum’ların

Scrum’ı ve bir de şirket seviyesinde Scrum’ların Scrum’ına sahibiz.

Ürün Seviyesinde Scrum’ların Scrum’ı

Bu toplantı oldukça önemliydi. Genelde haftada bir defa yaptık, kimi zamanlarsa daha sık.

Entegrasyon konularını, takım dengelerini, gelecek Sprint Planlama Toplantısı’nın hazırlıkları vb.

konuştuk. Bu toplantının süresini 30 dakika belirledik fakat genellikle bu süreyi aştık. Bunun

alternatifi Scrum’ların Scrum’ı toplantısını her gün yapmak olabilirdi fakat bunu hiç denemedik.

Scrum’ların Scrum’ı toplantısının yapısı:

Bir masa etrafında toplanır ve herkes, takımının geçen hafta neler yaptığını, önümüzdeki hafta neler

yapacağını, takımının önündeki engelleri anlatırdı.

Çapraz takımlardan herhangi birinin kaygısı anlatılırdı. Örneğin entegrasyon konusu:

Scrum’ların Scrum’ı toplantısının yapısı benim için çok önemli değildir. Önemli olan şey düzenli bir

şekilde Scrum’ların Scrum’ı toplantısını yapmaktır.

Spotify’da genelde beraber çalışan takımlar arasındaki “günlük senkronizasyon” toplantısı benzeri

bir yapıda yaparız. Kısa, en fazla 15 dakika süren bir toplantı. Toplantı da takımların durumundan

çok işlerin bağımlılıklara odaklanırız. Her takımdan bir kişi diğer takımlardan beklentilerini,

herhangi bir konuda engellerini anlatır. Çapraz takımlar bağımlılıkların takip etmek için yapışkan

kağıtlardan oluşturduğumuz basit bir duvar kullanırız. Toplantı senkronizasyona ihtiyaç olduğunu

gösteren bir pazar yerine dönüşür. Senkronizasyonun kendisi ayrı bir yerde oluşur. Toplantı bağımlılıklar konusunda kimin kiminle senkronize olması gerektiğini anlamamız için yardımcı olur.

133

Şirket Seviyesinde Scrum’ların Scrum’ı

Bu toplantıya “nabız” deriz. Bu toplantıyı farklı katılımcılarla birçok farklı formatta yaptık. Son

zamanlarda eski formatlardan vazgeçtik ve geliştirme bölümündeki herkesin katıldığı 15 dakikalık

toplantıya çevirdik.

Ne? 15 dakika mı? Geliştirme bölümündeki herkes mi? Tüm ürünleri geliştiren tüm takımların tüm

üyeleri mi? İşe yarıyor mu?

Evet. Eğer siz(ya da toplantıyı kim düzenliyorsa) toplantıyı kısa tutma konusunda disiplinli bir

tavırdaysa bitiyor.

Toplantının yapısı:

1. Geliştirme müdüründen haberler ve güncellemeler. Örneğin; yakın gelecekteki etkinliklerden

bilgiler.

2. Sırayla konuşma. Her ürün grubundan bir kişi geçen hafta ne yaptıklarını ve gelecek hafta ne

yapmayı planladıklarını ve önlerinde bir engel olup olmadığını anlatır. Diğer ekiplerden bazı

kişilerde rapor verebilirler, örneğin QA lideri.

3. Herkes bir şey sormakta ya da başka bir konuda bilgi vermekte özgürdür.

Bu kısa bir bilgilendirme toplantısıdır, bir tartışma ya da geri bildirim alma toplantısı değildir. Bu

şekilde yapılırsa 15 dakika genellikle yeterli oluyor. Bazen bu süreyi aştığımız oluyor fakat toplamda

30 dakikayı aştığımız çok nadirdir. Eğer ilginç konular çıkarsa araya girerim ve bu konuyu ilgi çekici

bulanları toplantıdan sonra bir araya getirir, konuşmalarını sağlarım.

Neden geliştirme ekiplerinin hepsinin katıldığı bir toplantı yapıyoruz? Çünkü şirket seviyesinde

yaptığımız Scrum’ların Scrum’ı toplantısı bir durum bildirime toplantısı şeklinde geçiyordu. Bu

toplantıyı yapan grup içinde çözüm getiren tartışmalar çok nadir yaşanıyordu. Ayrıca bu grup

dışındaki birçok kişi bu bilgileri öğrenmek istiyordu. Temelde takımlar diğer takımların neler yaptığını

bilmek istiyor. Eğer buluşacak ve her takımın neler yaptığı konusunda birbirimizi bilgilendireceksek ve

daha sonra gidip bunu kendi takımlarımızla paylaşacaksak “neden geliştirme ekiplerini bir araya

getirip hep beraber bu paylaşımı gerçekleştirmeyelim” dedik.

134

Gördüğünüz gibi Scrum’ların Scrum’ının yapısı içinde bulunduğunuz duruma göre değişiklik

gösterebilir. Herkese uyan tek bir yapı kesinlikle yoktur. Bazen şirketlerin beyin uyuşturucu, sıkıcı ve

verimsiz toplantıları her hafta(her gün) yaptıklarını gördükçe şok oluyorum. Gözleri donmuş insanlar

bir yerde toplanıyor ve bir yazıyı okuyarak durumlarını homurdanıyorlar. Bir Scrum zombisi olmayın!

Bir şeyi değiştirin! Deney yapın! Sürekli olarak birbirinize şuna benzer sorular sorun: “Bu toplantı

gerçekten değer katıyor mu? Daha fazla değer ekleyebilir mi? Daha fazla değer eklemesi için ne

yapmalıyız?” Sıkıcı toplantılar için hayat çok kısa!

Günlük Scrum’ları Boş Geçme

Eğer bir üründe çalışan birden çok Scrum Takımınız varsa ve hepsi Günlük Scrum Toplantısı’nı aynı

saatte yapıyorsa bir probleminiz var demektir. Ürün Sahibi(ve benim gibi her işe burnunu sokan

kişiler) her gün sadece bir takımın Günlük Scrum Toplantısı’na katılabilir.

Bu nedenle takımların aynı saatte Günlük Scrum yapmamalarını rica ederiz.

Yukarıda örnek bir zaman çizelgesi var. Günlük Scrum’ları takım odasından farklı odalarda yapıyoruz.

Toplantı süresi normalde 15 dakika fakat toplantı süresini aşma durumuna karşı her takımın 30

dakikası var.

Bu yaklaşım iki nedenden dolayı son derece yararlı:

Ürün Sahibi ve benim gibi kişiler bir sabahta tüm Günlük Scrum Toplantılarını ziyaret edebilirler.

Sprint’in nasıl gittiğini ve büyük engelleri belirlemenin daha iyi bir yolu yoktur.

Gördüğünüz gibi Scrum’ların Scrum’ının yapısı içinde bulunduğunuz duruma göre değişiklik

gösterebilir. Herkese uyan tek bir yapı kesinlikle yoktur. Bazen şirketlerin beyin uyuşturucu, sıkıcı

ve verimsiz toplantıları her hafta(her gün) yaptıklarını gördükçe şok oluyorum. Gözleri donmuş

insanlar bir yerde toplanıyor ve bir yazıyı okuyarak durumlarını homurdanıyorlar. Bir Scrum

zombisi olmayın! Bir şeyi değiştirin! Deney yapın! Sürekli olarak birbirinize şuna benzer sorular

sorun: “Bu toplantı gerçekten değer katıyor mu? Daha fazla değer ekleyebilir mi? Daha fazla değer eklemesi için ne yapmalıyız?” Sıkıcı toplantılar için hayat çok kısa!

135

Takımlar birbirlerinin Günlük Scrum Toplantıları’nı ziyaret edebilirler. Bu durum çok sık yaşanmaz

fakat bazen iki takım aynı alanda çalışıyor olabilir. Böyle durumlarda iki takımdan bazı üyeler

birbirlerinin Günlük Scrum Toplantıları’na katılırlar ve bilgilerini aynı seviyeye getirirler.

Negatif yönüyse takımın özgürlüğünün kısıtlanmasıdır. Günlük Scrum Toplantısı için istedikleri

zamanı belirleyemezler. Gerçi bu durum bizim için bir problem oluşturmadı.

Yangın Söndüren Takımlar

Büyük bir ürünün Scrum adaptasyonunda sorun yaşadığımız bir durum vardı. Çünkü bu takım yangını

söndürmek için çok fazla zaman harcıyordu. Erken teslimi yapılmış bir versiyonda sürekli hata

düzeltmeleri yapıyorlardı. Kısır bir döngü yaşıyorlardı, yangın söndürmekle o kadar meşguldüler k i

proaktif davranıp başka yangınların çıkmasını engellemeye vakitleri yoktu. Örneğin; tasarımı

iyileştirme, testleri otomatize etme, hataları izleme için araçlar geliştirme vs.

Bu sorunu çözmek için belirlenmiş kişilerden oluşan bir yangın söndürme takımı ve bir Scrum Takımı

oluşturduk.

Scrum Takımı’nın işi sistemi stabilleştirme ve proaktif bir şekilde yangınlar çıkmadan yangınları

önlemekti.

Yangın söndürme takımının(aslında biz bu takıma destek takımı diyorduk) iki işi vardı:

Yangınlarla savaşma.

Scrum Takımı’nı olası tüm rahatsızlıklardan koruma, örneğin nereden geldiği belli olmayan işlevsellik

taleplerini savuşturmak gibi.

Bu durum beni biraz rahatsız ediyor. Günlük Scrum’ın birinci amacı takım üyelerinin

birbirleriyle senkronize olmasıdır. Kendileri için uygun zamanı seçebilmelidirler. Benim gibi her

işe burnunu sokan insanları bilgilendirmek ikincil öncelikli amaçtır. Evet takımların farklı zamanlarda Günlük Scrum yapması iyidir fakat bunu takımlara zorla yaptırmayın.

136

Yangın söndürme takımı kapıya yakın bir yerde otururken, Scrum Takımı odanın arka bölümünde

oturuyordu. Yani yangın söndürme takımı fiziksel anlamda Scrum Takımını, kızgın müşterilerden ya

da sabırsız satış elemanlarından koruyordu.

İki takımda da deneyimli yazılım geliştiriciler bulunuyordu. Böylece iki takım çekirdek yetkinliklerde

birbirine bağımlı olmadı.

Bu girişimin temelde amacı Scrum’a başlamanın getirdiği problemi çözmekti. Eğer takım bir gününü

bile planlamakta zorlanıyorsa Scrum yapmaya nasıl başlayabiliriz? Yukarıda bahsettiğim gibi

stratejimiz takımı ikiye bölmekti.

Bu işe yaradı. Scrum Takımı proaktif bir şekilde çalışacak zaman buldu ve sonunda sistemi stabil bir

hale getirdi. Bu zaman içinde yangın söndürme takımı plan yapmaktan tamamıyla vazgeçti, reaktif bir

şekilde çalıştı ve çıkan problemleri anında çözmeye çalıştı.

Elbet Scrum Takımı tamamıyla dikkat dağıtıcılardan arınmış değildi. Yangın söndürme takımı Scrum

Takımı’ndaki önemli kişileri ya da Scrum Takımı’nın tamamını sık sık problem çözümlerine dahil

etmek zorunda kaldı.

Her neyse birkaç aydan sonra sistem yeterince stabil bir hale getirildi ve yangın söndürme ekibinden

birkaç yeni Scrum Takımı oluşturduk. Yangın söndürücüler hırpalanmış kasklarını çıkarmaktan ve

Scrum Takımı’na katılmaktan oldukça mutluydu.

Mükemmel bir model fakat sadece geçici kriz yönetimi için kullanılabilir. Normal şartlar altında

yangın söndürme ekiplerine ihtiyaç duymamalısınız. Eğer diğer takımları yangından izole ederseniz

yeni yangınları engellemeyi öğrenemezler. Bunun yerine problemleriniz ve yangınınız varsa(ki

neredeyse tüm şirketlerde vardır) bununla takımın başa çıkmasını öğrenmesine izin verin. Birçok

takım, takım içinde dönüşümlü şekilde yangın söndürücü rolü oluşturur. Basit ve etkilidir. Bu

yaklaşım takımın diğer üyelerine yangın çıkartmayan kod yazma şevki verir.

Eğer zamanında bilseydim yangın söndürme takımı için kesinlikle Kanban kullanırdım.

137

Ürün İş Listesi’ni Bölmek ya da Bölmemek?

Diyelim ki bir ürününüz ve iki Scrum Takımınız var. Kaç Ürün İş Listeniz olmalı? Kaç Ürün Sahibiniz

olmalı? Bunun için üç model değerlendirdik. Bu modellerden birinin seçiminin Sprint Planlama

Toplantısı’na etkisi büyüktür:

Strateji 1: Bir Ürün Sahibi ve Bir Ürün İş Listesi

Bu model “Sadece Bir Tane Olabilir” modelidir ve bizim tercih ettiğimiz modeldir.

Bu modelin iyi yönü Ürün Sahibi’nin önceliklerine göre Takımların yeni bir şekle bürünmesine izin

vermesidir. Ürün Sahibi, neye ihtiyacı olduğuna odaklanabilir ve işin nasıl bölüneceğinin kararını

takımların vermesine izin verir.

Daha somut olarak takımın Sprint Planlama Toplantısı şöyledir:

Sprint Planlama Toplantısı bir konferans odasında yapılır.

Toplantıdan önce Ürün Sahibi bir duvarı Ürün İş Listesi olarak belirler ve önceliklendirilmiş kullanıcı

hikayelerini bu duvara yapıştırır. Duvarda yer kalmayana kadar kullanıcı hikayelerini yapıştırır ki

genelde bir Sprint için bu kadar iş yeterlidir.

138

Her Scrum Takımı boş bir duvar seçer ve takım adını yazar. Bu o takımın duvarı olmuştur. Daha sonra

takımlar öncelik sırasına göre Ürün İş Listesi duvarından kullanıcı hikayelerini seçer ve kendi

duvarlarına yapıştırırlar.

Aşağıdaki resim bunu gösteriyor. Sarı oklar, Ürün İş Listesi’ndeki kullanıcı hikayelerinin takım

duvarlarına akışını simgeler.

Toplantı ilerledikçe Takımlar ve Ürün Sahibi, kullanıcı hikayeleri üzerine pazarlık yaparlar, kullanıcı

hikayeleri Takımlar arasında dolaşır, aşağıya yukarıya taşınır ve öncelikleri değiştirilir, daha küçük

139

maddelere bölünür vb. Aşağı yukarı bir saatten sonra her takım duvarında Sprint Planlaması için ilk

versiyonunu oluşturmuştur. Bundan sonra Takımlar bağımsız çalışır, işleri daha küçük parçalara ayırır

ve işler için zaman tahmininde bulunurlar.

Dağınık, karmaşık ve yorucu fakat verimli, eğlenceli ve sosyal! Zaman dolduğunda tüm takımlar

Sprint’e başlamak için gerekli bilgiye sahip olurlar.

Strateji 2: Bir Ürün Sahibi ve Birden Fazla Ürün İş Listesi

Bu stratejide Ürün Sahibi, her takım için bir Ürün İş Listesi oluşturur. Bu yaklaşımı denemedik fakat

denemeye yakınız. İlk stratejimiz başarır olursa bu yaklaşımı kullanabiliriz.

Bu stratejinin zayıf noktası Ürün Sahibi’nin, kullanıcı hikayelerini takımlara paylaştırmak zorunda

olmasıdır, muhtemelen takımlar bu konuda Ürün Sahibi’nden daha başarılıdırlar.

Bu model oldukça yaygınlaşmaya başladı. Hatta Çevik yazılım geliştirme için yeni çerçeveler

oluşturulmasını bile sağladı, örneğin SAFe(Scaled Agile Framework). Son dönemde LEGO’da

130’dan fazla kişiyle iki günlük planlama etkinliği gerçekleştirdik. Bazen bu teknik altı aylık

planlamalar için geçici bir ölçü olarak kullanılıyor. Takımların birbirinden daha bağımsız planlama yapabilecekleri bir takım yapısı ve mimari bulana kadar yapmaya devam edeceğiz.

140

Strateji 3: Birden Fazla Ürün Sahibi ve Her Ürün Sahibi için Bir Ürün

İş Listesi

Bu ikinci stratejiye benziyor, her takım için bir Ürün İş Listesi ve aynı zamanda her takım için bir Ürün

Sahibi!

Bunu şimdiye kadar denemedik ve muhtemelen denemeyeceğiz.

Eğer iki Ürün İş Listesi aynı kod alt yapısını içeriyorsa muhtemelen iki Ürün Sahibi arasında ciddi çıkar

çatışmalarına neden olabilir.

Eğer iki Ürün İş Listesi farklı kod alt yapılarını içeriyorsa temelde büyük bir ürünü daha küçük alt

ürünlere bölmekle ve birbirinden bağımsız geliştirmekle aynı şeydir. Bunun anlamı da bir takım için

bir ürün durumuna geri dönmektir ki bu basit ve güzeldir.

Genelde Ürün Sahibi, darboğaza dönüşüyor.

141

Kod Branch’leme

Aynı kod alt yapısından çalışan birden fazla takımla yazılım konfigürasyon yönetim sisteminde kod

branch’lemeyle kaçınılmaz olarak başa çıkmak zorundaydık. Aynı kod alt yapısında birden fazla kişinin

çalışmasıyla ilgili birçok kitap ve makale bulunur. Bu yüzden detaylara girmeyeceğim. Yeni ya da

devrimsel bir şey söylemeyeceğim. Yine de takımlarımızdan şimdiye kadar öğrendiğimiz dersleri

özetleyeceğim:

Trunk’ı sabit tutma konusunda katı olun. Bunun anlamı her şeyin derlenebilmesi ve bütün birim

testlerinin çalışır olmasıdır. Herhangi bir anda çalışabilir bir teslim yapmak mümkün olmalıdır.

Tercihen sürekli derleme sistemi(continuous build) her gece tüm kodları derlemeli ve test ortamına

otomatik teslim işlemini gerçekleştirmelidir.

Her teslimi etiketleyin. Kabul testi veya üretim ortamı için ne zaman teslim yaparsanız yapın neyin

teslimini yapıldığını açık açık anlatan versiyon etiketiniz olduğundan emin olun. Bunun anlamı

gelecekte ihtiyacınız olduğunda geri dönebilmenizdir.

Sadece gerekli durumlarda yeni branch’ler oluşturun. Bunun için iyi bir genel kural var olan kod alt

yapısını o kod alt yapısının kurallarını çiğnemeden geliştirme yapamıyor olmanızdır. Eğer şüpheniz

varsa yeni bir branch oluşturmayın. Neden? Çünkü her aktif branch yönetim ve karmaşıklık

maliyetine neden olur.

Branch’leri farklı yaşam döngülerini birbirinden ayırmak için kullanın. Her Scrum Takımı’nın kendi kod

alt yapısında yani kendi branch’inde kodlama yapıp yapmamasına karar verebilirsiniz. Fakat kısa

vadeli çözümleri uzun vadeli çözümlerle karıştırırsanız kısa vadeli çözümleri teslim etmenin çok zor

olduğunu öğreneceksiniz.

Spotify’da kullanılan model budur. 70’ten fazla takımın kendi Ürün Sahibi ve kendi Ürün İş Listesi

vardır. Aslında bazı durumlarda Strateji 1’i(bir Ürün İş Listesi ve birden fazla takım) kullanıyoruz

fakat takımların büyük çoğunluğunda bir Ürün Sahibi ve bir Ürün İş Listesi vardır. Bunun iyi yönü

çok nadir büyük planlama toplantılarına ihtiyaç duyarız. Kötü yönüyse bunu yapabilmek için

mimariyi ayrıştırmaya çok fazla efor harcamamızdır. Her zaman olduğu gibi avantajlar ve

dezavantajlar var. Bu nedenle deney yapmaya devam edin. Bunu çok fazla tekrarladım değil mi? :)

142

Sık sık senkronize olun. Eğer bir branch’te çalışıyorsanız çalışan bir şey geliştirdiğinizde hemen ana

branch’le senkronize olun. İşe gittiğiniz her gün ana branch ve kendi branch’inizle senkronize olun.

Böylece diğer takımların yaptığını değişiklikleri almış olursunuz. Eğer bu size merge cehennemini

yaşatıyorsa beklerseniz daha kötü olacağı gerçeğini kabul edin.

Birden Fazla Takımla Retrospektif

Aynı ürün üzerinden birden fazla takım çalıştığında retrospektif toplantılarını nasıl yapıyoruz?

Sprint demosundan ve alkışlardan hemen sonra her takım kendi odasına ya da ofis dışında rahat

edebilecekleri bir yere gider. Sprint Retrospektifleri bölümünde anlattığıma benzer bir şekilde

retrospektif toplantılarını yaparlar.

Sprint Planlama Toplantısı’nda(her takım bu toplantıya katılır çünkü senkronize Sprint’ler koşuyoruz)

ilk yaptığımız şey her takımdan seçilen birinin yaptıkları retrospektif toplantısının önemli noktalarını

özetlemesidir. Bir takım için beş dakika kadar zaman alır. Daha sonra 10-20 dakika arasında bir açık

konuşma seansımız olur, ara veririz ve gerçek Sprint Planlama Toplantısı’na başlarız.

Başka bir yol denemedik, bu yeterince iyi gidiyor. En büyük dezavantaj Sprint Retrospektif

bölümünden sonra Sprint Planlama bölümünden önce boş zaman olmamasıdır.

Bu tavsiye hala geçerli. Sadece etiketleme konusunda şimdiki sistemler daha başarılı ve otomatik

olarak bu işi gerçekleştiriyorlar. GIT gibi modern versiyon kontrol sistemleri sık sık commit

yapmamak için bir bahane olamaz. Trunk’ı temiz tutun, sık sık teslim yapın ve branch’lerinizin

ömrü kısa olsun. Bu konuda bir makale yazdım. http://www.infoq.com/articles/agile-version-control

GIT gibi sistemlerin merkezi olmayan versiyon kontrol sistemi olarak adlandırılmasını fakat neredeyse her projenin merkezi bir repo ve ana branch kullanmasını eğlenceli buluyorum.

Kesinlikle! Bu oldukça büyük bir dezavantajdır! Bu nedenle bugünlerde birbirine bağımlılığı olan

takımlar olduğunda retrospektif özetleri bölümünü gerçek retrospektif toplantısı içinde yapmayı

tercih ediyorum. Her takım kendi retrospektif toplantısını yapar aşağı yukarı bir saat sonra büyük

bir oda da herkes bir araya gelir. Her takım kendi retrospektif toplantısının çıktılarını özetler ve

çözülmemiş en önemli engellerini listeler. Her takım konuştuktan sonra A engelinin çapraz

takımlar içindeki en büyük engel olduğu ortaya çıkar(örneğin; “takımlar arasında tutarlı olmayan

Bitti Tanımı” ya da “trunk’ın stabil olmaması”). Küçük bir atölye çalışması yapmak ya da

problemin çözümünü gönüllü olarak yapacak kişileri bulmak için mükemmel bir fırsat. Bazen

sorunun çözümü birkaç saat alabilir. Bu nedenle Sprint Planlama Toplantısı’nı bir gün sonra yapmak iyi olabilir.

143

Bir takım olduğunda planlama toplantısında retrospektif özeti seansı bölümünü yapmayız. Gerek yok

çünkü herkes takımın retrospektif toplantısındaydı.

Herkese uyan tek bir model yoktur! İçinde bulunduğunuz duruma göre bir yaklaşım çok başarılı da

olabilir ya da tamamıyla bir hüsranla da sonuçlanabilir.

144

Bölüm

OnAltı

Dağıtık Takımlarla Nasıl Çalıştık?

Takım üyeleri farklı lokasyonlarda olduğunda ne olur? Scrum ve XP “büyüleri” takımlar aynı

lokasyonda bulunduğunda, takım üyeleri sıkı bir iş birliği içinde olduğunda ve yüz yüze iletişim

olduğunda işe yarar.

Coğrafik olarak farklı yerlerde olan takımlarımız ve zaman zaman evden çalışan takım üyelerimiz var.

Bu durum için stratejimiz oldukça basit. Aynı lokasyonda olmayan takımlar arasında iletişim

frekansını artırabilmek için her numarayı deneriz.

- Eşli programlama yapabilme

- Günlük Scrum’ları yüz yüze yapabilme

- Herhangi bir anda yüz yüze konuşabilme

- Fiziksel olarak bir araya gelme ve sosyalleşme

- Tüm takımla spontane toplantılar

- Sprint İş Listesi’nde, burn-down grafikte, Ürün İş Listesi’nde ve diğer bilgi yayıcılarda aynı

görüntüyü görebilme

Kullanmaya çalıştığımız tekniklerden bazıları:

- Her bilgisayarda webcam ve kulaklık

- Uzaktan bağlantı yapılabilen içinde webcam bulunan konferans odaları, konferans

mikrofonları, her zaman hazır bilgisayarlar ve ekran paylaşımı için bir ürün vb.

- Her ofiste diğer ofisleri gösteren büyük ekranlar. Bir bakıma iki ofis arasında sanal bir

penceredir. Bu ekran karşısında geçebilir ve el sallayabilirsiniz. ☺ Kim masasında ve kim

kiminle konuşuyor görebilirsiniz. Bu yöntem insanlara “bu işte beraberiz” hissi verir.

145

- Değişim programları, çalışanlar birbirlerinin ofislerini düzenli olarak ziyaret edebilirler.

Bu teknikleri kullanarak yavaş yavaş fakat emin adımlarla coğrafik olarak farklı yerlerde bulunan

takım üyeleriyle Sprint Planlama Toplantıları’nı, demoları, retrospektifleri ve Günlük Scrum’ları

yapmaya yaklaşıyoruz.

Her zaman olduğu gibi: Gözlem => Adaptasyon => Gözlem => Adaptasyon => Gözlem => Adaptasyon

=> Gözlem => Adaptasyon => Gözlem => Adaptasyon => Gözlem => Adaptasyon =>

Üretimin Bazı Aşamalarının Ülke Dışında Gerçekleştirilmesi

(Offshoring)

Ülke dışından destek aldığımız birkaç takımımız bulunuyor ve Scrum kullanarak bu durumla nasıl başa

çıkacağımıza dair deneyler yapıyoruz.

Bu konuda iki ana stratejimiz var: ayrı takımlar ve ayrı takım üyeleri.

İlk strateji yani ayrı takımlar çekici seçenek olsa bile biz ikinci stratejiyle(ayrı takım üyeleriyle)

başladık. Bunun birkaç nedeni var:

1. Takım üyelerinin birbirlerini iyi tanımalarını isteriz.

2. İki ofis arasında mükemmel iletişim alt yapısı ve bunu kurmak için takımları harekete geçirici

bir teşvik vermek isteriz.

3. Başlangıçta diğer ofisteki takım kendi kendilerine verimli bir Scrum Takımı olmak için çok

küçüktü.

4. Bağımsız bir takım olmaları için ilk aşamada yoğun bilgi paylaşımı yapmak istedik.

Uzun vadede elbet “ayrı takımlar” stratejisine geçebiliriz.

Dağıtık takımlar her yerde. Açık kaynak kodlu projelerin çoğu tamamıyla dağıtık takımlar

tarafından geliştiriliyor. Yani dağıtık takımlarla çalışılabileceğine dair bir şüphe yok. Yine de aynı

odada beraber oturan, aynı hedefe odaklanmış, çapraz fonksiyonel küçük bir takımın verimliliğini

geçemez. Bu nedenle öncelik aynı ofiste bulunan takımlar oluşturmak olmalıdır. Eğer bunu

sağlayamıyorsanız önceliğiniz mümkün olduğunca yakın takımlar oluşturmak olabilir. Eğer farklı

lokasyonlarda bulunan takım üyelerine sahip olmanız gerekiyorsa yukarıda bahsettiğim araçlar ve

teknikler zararı indirgemek için kullanılabilir. Yani cimri davranmayın, paranın alabileceği en iyi araçları alın! Beraber çalışan bir takım kadar asla verimli olamayacaksınız fakat yaklaşabilirsiniz.

146

Evden Çalışan Takım Üyeleri

Bazen evden çalışmak gerçekten iyi olabilir. Bazen evde geçirdiğiniz bir günde ofiste geçirdiğiniz bir

haftadan daha fazla kod yazabilirsiniz. Eğer çocuğunuz yoksa ☺

Yine de Scrum’ın temellerinden biri tüm takımın aynı yerde bulunmasıdır. Peki ne yapacağız?

Temelde ne zaman ve ne kadar sıklıkta evden çalışmak problem olmaz kararını takımlara bırakıyoruz.

Bazı takım üyeleri uzun süre yolculuk yapmamak ve trafikte zaman harcamamak için düzenli olarak

evden çalışır. Yine de çoğu zaman takımların aynı yerde bulunmaları için cesaretl endiririz.

Takım üyeleri evden çalıştığı zaman Günlük Scrum’a Skype’ın sesli aramasını(bazen görüntülü)

kullanırlar. Anında mesajlaşmak için gün boyunca online’dırlar. Elbet aynı odada bulunmak gibi değil

fakat bizim için yeterince iyi.

Bu oldukça iyi bir stratejidir. Uzun vadede aynı yerde bulunan takımlar istiyorsunuz. Çünkü bir

dağıtık takım aynı takımdaşlığı oluşturamıyor. Bu nedenle başlangıçta dağıtık bir takımınız(takım

üyelerinin farklı ofislerde bulunduğu takım) olsa bile her ofiste farklı takımlar oluşturmanın

yollarını arayın. İki takım arasındaki bağımlılıklar ve iletişimle ilgili sorunlarla yine başa çıkmanız

gerekecek fakat diğer seçenekteki problemlerle karşılaştırınca bu problemler daha basittir.

İyileştirilmiş günlük iletişime ek olarak ana kazançlardan biri motivasyondur. Takım

arkadaşlarınızla aynı odada bulunmak eğlencelidir! Motive olmuş insanlar daha iyi ürünleri daha

hızlı geliştirirler.

147

Çarşamba günlerini odak günü olarak belirlediğimiz bir deneyimiz oldu. Yani “eğer evden çalışmak

istiyorsanız çalışabilirsiniz fakat bunu Çarşamba günü yapabilirsiniz, tabi takımın olurunu alarak”.

Bunu denediğimiz ilk takımda oldukça başarılı bir şekilde çalıştı. Takım üyelerinin büyük çoğunluğu

Çarşambaları evde kaldı ve birçok kullanıcı hikayesini bitirdi. Sadece bir gün olduğu için takım üyeleri

arasındaki bilgi senkronizasyonu bozulmadı. Bazı nedenlerden dolayı diğer takımlarda bu yöntem hiç

işlemedi.

Büyük resme bakarsak evden çalışan insanlar bizim için bir problem olmadı.

Scrum’ın yapı taşlarından biri kendi kendini yöneten takımdır. Bunun önemi anlatılamaz! Takıma

mümkün olduğunca sorumluluk verilmelidir. Bu sorumluluk içinde çalışma saatleri ve evden

çalışma kuralları gibi şeyler de olabilir. Kendi kendini yönetme yaratıcılık, motivasyon, yenilikçilik

ve diğer birçok iyi şey için anahtardır! Bazı yöneticiler, takımların bu güveni suiistimal

edeceğinden korkar fakat pratikte takımların suiistimal ettiğini çok nadir gördüm. Takımlar

teslimini yaptıkları üründen net bir şekilde sorumlu tutulduktan sonra bu sorumluluğun hakkını

verecek şekilde hareket etme eğilimindedirler.

Şimdilerde güzel ve ücret olarak karşılanabilir birçok iletişim sistemi bulunuyor. Örneğin Double

Robotics’e bakabilirsiniz. http://doublerobotics.com. En basit haliyle tekerlekleri bulunan bir

çubuk üzerinde iPad satıyorlar. Tıpkı bir Skype görüşmesinde olmak gibi fakat etrafta

gezinebiliyorsunuz! Oldukça fazla kullanmaya başladım. Başka bir ofise ışınlanıyormuşsunuz gibi hissettiriyor!

148

Bölüm

OnYedi

Scrum Master Kontrol Listesi

Son bölümde size Scrum Master Kontrol Listemizi anlatacağım. Bu liste bir Scrum Master’ın en yaygın

olarak yaptığı fakat unutması kolay olan rutin yönetimsel işleri içerir. “Engellerin kaldırılması” gibi

açık şeyleri atladık.

Sprint Başlangıcı

- Sprint Planlama Toplantısı’ndan sonra Sprint Bilgi Sayfasını oluşturulur.

o Wiki’ye bu sayfanın bağlantısı eklenir.

o Bilgi sayfasının çıktısı alınır ve herkesin görebileceği takıma yakın bir duvara asılır.

- Yeni Sprint’in başladığına dair herkese duyuru epostası gönderilir. Bu epostaya Sprint Bilgi

Sayfası’nın bağlantısı ve Sprint Hedefi eklenir.

- Sprint istatistikleri dokümanı güncellenir. Bu dokümana tahmini takım hızı, takımdaki

kişilerin kimler olduğu ve Sprint uzunluğu gibi bilgiler eklenir.

Her gün

- Günlük Scrum Toplantısı’nın zamanında başladığından ve bittiğinden emin olunur.

- Gerektiğinde Sprint İş Listesi’ne kullanıcı hikayeleri ekleme, çıkarma.

o Ürün Sahibi’nin bu değişikliklerden haberdar olmasını sağlama.

- Sprint İş Listesi’nin ve burn-down grafiğin Geliştirme Takımı tarafından güncellenmesini

sağlama.

Ayrıca bu listeye de bakabilirsiniz. https://www.crisp.se/gratismaterial-och-guider/scrum-checklist Resmi olmayan resmi Scrum Master Kontrol Listesi’dir. O kadar çok kullanılmaya başlandı ki resmi olmasa da resmi bir kontrol listesi gibi oldu.

149

- Problemlerin ya da engellerin ortadan kaldırılması, kaldırılamayan problemlerin, engellerin

Ürün Sahibi’ne ya da müdüre raporlaması.

Sprint Sonu

- Sprint demo’sunu düzenleme.

- Bir ya da iki gün önceden herkesin Sprint demo’su hakkında bilgilendirilmesi.

- Geliştirme Takımı ve Ürün Sahibi’nin katıldığı retrospektif çalışmasını yapma. Geliştirmeden

sorumlu müdür Retrospektif Toplantısı’na çağırılabilir böylece diğer takımlardaki pratiklerin

paylaşımı yapılabilir.

- Sprint istatistikleri dokümanının güncellenmesi(Takım hızının ve retrospektifte öne çıkan

önemli konuların eklenmesi).

Küçük kullanışlı bir liste. Zamanla kendinizi bu işlerden soyutlayın, Takımın bu işleri siz olmadan yapabilmesi için koçluk yapın. Takımın bu işleri siz olmadan yapabilmesi konusunda başarısız olsanız bile bu deneme hareketi sizi iyi şeylere yönlendirecektir. Bazı Scrum Master'lar Scrum yöneticisi ya da Scrum'ın kölesi olurlar çünkü Takımı memnun etmeye odaklanmışlardır. Eğer Takım Scrum Master'a çok fazla bağlanırsa, kendi kendini yönetme yeteneğini kaybetmeye başlar. Takım, Scrum'a yeniyse ve sizin yardımınıza ihtiyacı varsa başlangıçta bu büyük bir problem değildir. Fakat zamanla yönetimsel işlerden yavaş yavaş çekilmeli ve Takıma daha fazla sorumluluk vermelisiniz. Böylece engelleri kaldırmak ya da kod yazmak, test yapmak gibi Scrum Master'la ilgili olmayan işler için daha fazla vaktiniz olacaktır.

150

Bölüm

OnSekiz

Son Sözler

Bu kadar uzun olacağını düşünmemiştim.

İster yeni başlayan biri ister bir Scrum emektarı olun umarım bu kitap size yararlı bilgiler sağlar.

Scrum içinde bulunulan çevreye göre şekillendirilebildiğinden genel olarak iyi pratikleri tartışmak

zordur. Yine de sizin tecrübelerinizi duymayı isterim. Yaklaşımınızın benimkinden farklılaştığı yerleri

anlatın. Yaklaşımımı iyileştirebilmek için fikirler verebilirsiniz!

Henrik.kniberg@crisp.se adresinden benimle iletişime geçebilirsiniz.

scrumdevelopment@yahoogroups.com adresine de arada bir göz atıyorum.

Eğer kitap hoşunuza giderse bloğuma da bakabilirsiniz. Umarım Java ve Çevik Yazılım Gelişt irme

üzerine yeni makaleler ekleyebilirim. http://blog.crisp.se/henrikkniberg/

Ohh, unutmayın. Bu sadece iş!

Şimdi blog’da birçok makale ve video bulunuyor! Sadece benim yazdıklarım değil Crisp’teki iş arkadaşlarımın, partnerlerimin ve arkadaşlarımın yazdıkları da var. Gerçekten altın madeni gibi! Zaman zaman Twitter’da da oldukça aktifim.(@henrikkniberg)

Neden bu kadar eposta aldığım belli oldu. Geribildirimleriniz için çok teşekkür ederim eğer cevap veremezsem lütfen alınmayın. Arada bir ben de hayatım varmış gibi davranıyorum.

151

Okuma Önerileri

Aşağıda bana çok şey kazandıran birkaç kitabı paylaşıyorum. Kesinlikle okumalısınız!

Hmm…bunu gerçekten güncellemeliyim. 2007 yılından beri birçok ilginç kitap okudum! Fakat bu ayrı bir yazı olacaktır. #cliffhanger

152

Yazar Hakkında

Henrik Kniberg(henrik.kniberg@crisp.se), Stockholm’de bulunan Crisp(www.crisp.se) şirketinde

danışmandır. Java ve Çevik Yazılım Geliştirme konularında uzmandır.

İlk XP kitapları ve Çevik Bildiri ortaya çıktığından beri Henrik Çevik İlkeleri benimsemiş ve farklı

organizasyonlarda bu ilkelerin verimli bir şekilde nasıl uygulanabileceğini öğrenmeye çalışmıştır.

Goyoda’nın(1998-2003) kurucu ortağı ve teknolojiden sorumlu yöneticisi olarak TYG’yi ve diğer Çevik

Pratikleri birçok defa deneyimleme şansını elde etmiştir. Goyoda’da 30 kişinin geliştirdiği teknik bir

platformu yönetmiştir.

2005 yılının sonlarında İsveçli bir oyun geliştirme firmasında anlaşmalı olarak yazılım geliştirme

bölümünün başkanlığını yaptı. Şirket organizasyonel ve teknik problemlerden kaynaklanan bir kriz

içindeydi. Henrik, Scrum ve XP'yi araç olarak kullanarak Çeviklik ve Yalınlık ilkelerinin şirketin bütün

seviyelerinde uygulanmasını sağladı ve şirketi krizden çıkardı.

2006 yılının Kasım ayında bir Cuma günü Henrik ateşi çıkmış bir halde yatıyordu. Geçen bir yılda neler

öğrendiğini görmek için notlar çıkarmaya başladı. Bir kere yazmaya başladığında kendini

durduramadı. Çılgınca yazmalar ve çizmelerle geçen üç günün sonunda başlangıç notları 80 sayfaya

ulaşmış bir makale olmuştu. Bu makalenin adı Siperden Scrum ve XP’idi. Sonunda bu kitap

okuduğunuz kitaba dönüştü.

Henrik, holistik yaklaşımı benimsemiştir. Bu nedenle müdür, geliştirici, Scrum Master, öğretmen ve

koç gibi farklı rollerde bulunmaktan hoşlanır. Mükemmel yazılımlar ve mükemmel takımlar

geliştirmeleri için şirketlere yardım eder, Henrik için belirlenen rolün önemi yoktur.

Henrik Tokyo’da büyüdü ve şimdi eşi Sophia ve iki çocuğuyla Stockholm’de yaşıyor.

Boş zamanlarında aktif bir müzisyendir. Yerel gruplarda bass ve keyboard çalıyor ve beste yapıyor.

Daha fazla bilgi için: http://www.crisp.se/henrik.kniberg

Aynı aile ve çocuklar, sadece artık daha fazlalar. Fazla olan çocuklar :) Artık 4 çocuğu var.

Sadece bir hafta sonunda bu kadar yazabildiğim için kendime şaşırıyorum! Bu kitaptan dolayı diğer yazarlar benden nefret ediyor!

Bugünlerde daha çok yönetim danışmanı, organizasyonel araştırmacı ve Çeviklik/Yalınlık konularında koç olarak çalışıyorum. En basit haliyle şirketlerin daha iyi bir hale gelmeleri için yardım ediyorum. Gerçi zaman zaman kod yazıyorum sadece hobi olarak.