Siperden Scrum ve XP, Biz Nasıl Yapıyoruz?
Çevirenin Önsözü
“Kanban ve Scrum, İkisininde 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ı, “Siperden Scrum ve XP, Biz Nasıl Yapıyoruz?”, ç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
Kitabı indirebileceğiniz bağlantı:
Scrum ve XP İçerik
Çevirenin Önsözü
Bilgilendirme
Jeff Sutherland’in Önsözü
Mike Cohn’un Önsözü
Önsöz: Scrum işe yaradı!
İkinci Basımın Önsözü
Bölüm Bir
Giriş
Açıklama
Neden Yazdım?
Ama Scrum Ne ki?
Bölüm İki
Ürün İş Listesi’ni nasıl oluştururuz?
Ürün İş Listesi’ndeki Diğer Alanlar
Ürün İş Listesi’ni İş Birimine(Müşteriye) Anlamlı Gelecek Seviyede Tutma
Bölüm Üç
Sprint Planlama’ya Nasıl Hazırlanıyoruz?
Bölüm Dört
Sprint Planlama’yı Nasıl Yapıyoruz?
Ürün Sahibi Neden Katılmak Zorunda?
Kalitenin Neden Pazarlığı Olmaz?
Bitmeyen Sprint Planlama Toplantıları!
Sprint Planlama Toplantısı’nın Yapısı
Sprint Uzunluğunu Belirleme
Sprint Hedefi’ni Belirleme
Sprint’e Hangi İşlerin Alınacağını Belirleme
Sprint’e Hangi İşlerin Alınacağı Konusunda Ürün Sahibi’nin Etkisi Nedir?
Sprint’e Hangi İşlerin Alınacağına Geliştirme Takımı Nasıl Karar Verir?
İçgüdüsel Karar Verme
Geliştirme Takımı’nın Hızını Hesaplama
İşlerin Büyüklüğünü Belirlerken Hangi Tekniği Kullanıyoruz?
İndeks Kartlarını Neden Kullanıyoruz?
Bitti Tanımı
Planlama Poker ile Efor Tahmini
Kullanıcı Hikayelerini Netleştirme
Kullanıcı Hikayelerini Küçük Parçalara Bölme
Kullanıcı Hikayelerini İşlere Bölme
Günlük Scrum için Yer ve Zaman Belirleme
Çizgiyi Nereye Çekmeliyiz?
Teknik Kullanıcı Hikayeleri
Hata Takip Sistemi mi? Ürün İş Listesi mi?
Sprint Planlama Toplantısı Sonunda Biter
Bölüm Beş
İletişimi Nasıl Gerçekleştiriyoruz?
Bölüm Altı
Sprint İş Listesi’ni Nasıl Oluştururuz?
Sprint İş Listesi’nin Formatı
Scrum Duvarı Nasıl Kullanılır?
Örnek 1: İlk Günlük Scrum’dan sonra
Örnek 2: Birkaç gün sonra
Burn-down Grafik Nasıl Oluşturulur?
Scrum Duvarı’nda Uyarı İşaretleri
Takip Edilebilirlik?
Tahminler Günlük mü, Saatlik mi Olmalı?
Bölüm Yedi
Takım Odasını Ayarlama
Takım Beraber Otursun!
Ürün Sahibi’ni Yakında Tutun
Müdürleri ve Koçları Yakında Tutun
Bölüm Sekiz
Günlük Scrum’ları Nasıl Yapıyoruz?
Scrum Duvarı’nı Güncelleme
Geç Gelenlerle Başa Çıkma
“Bugün Ne Yapacağımı Bilmiyorum”cularla Başa Çıkma
Bölüm Dokuz
Sprint Demo’larını Nasıl Yapıyoruz?
Bütün Sprint’lerin Bir Demo’yla Bitmesinde Neden Israr Ediyoruz?
Sprint Demo’lar için Kontrol Listesi
Demosu Yapılamayacak İşler
Bölüm On
Sprint Retrospektifleri Nasıl Yapıyoruz?
Neden Bütün Takımların Retrospektif Yapması Konusunda Israr Ediyoruz?
Retrospektifleri Nasıl Organize Ederiz?
Takımlar Arası Bilgi Paylaşımı
Değişmeli ya da Değişmemeli
Retrospektifte Ortaya Çıkan Örnekler
“Kullanıcı hikayelerini daha küçük kullanıcı hikayelerine ya da işlere bölmek için daha fazla zaman ayırmalıyız”
“Dikkat dağıtan şeyler”
“Sprint’e fazla iş alıyoruz ve aldıklarımızın yarısını bitirebiliyoruz”
“Ofisimiz çok gürültülü ve dağınık”
Bölüm Onbir
Sprint’ler arasında boş zaman
Bölüm Oniki
Teslim planlamasını ve sabit fiyat anlaşmalarını nasıl yapıyoruz?
Kabul Eşiklerinizi Belirleyin
En Önemli İş Maddelerinin Zaman Tahmini
Takım Hızını Tahmin Etme
Her Şeyi Teslim Planında Birleştirme
Teslim Planını Uyarlama
Bölüm Onüç
Scrum ve XP’yi Beraber Nasıl Kullanıyoruz?
Eşli Programlama
Test Yönelimli Geliştirme (Test Driven Development)
Yeni Projelerde TYG
Eski Projelerde TYG
Artımlı Tasarım
Sürekli Entegrasyon
Ortak Kod Sahipliği
Bilgilendirici Çalışma Alanı
Kodlama Standartları
Sürdürülebilir Hız / Enerjik İş
Bölüm Ondört
Nasıl Test Yapıyoruz?
Muhtemelen Kabul Testi Aşamasından Kurtulamazsınız
Kabul Testi Aşamasını En Aza İndirme
Testçileri Scrum Takımı’nın İçine Yerleştirerek Kaliteyi Artırma
Testçi, Onay Veren Adam
Test Yapılacak Bir şey Olmadığında Testçi Ne Yapar?
Sprint’te Daha Az İş Yaparak Kaliteyi Artırma
Kabul Testi Aşaması, Sprint’in Bir Parçası mıdır?
Sprint Döngüleri mi, Kabul Testi Döngüleri mi?
Yaklaşım 1: “Eski Kullanıcı Hikayelerini Üretim Ortamına Almadan Yeni Kullanıcı Hikayelerini Geliştirmeye Başlamayın”
Yaklaşım 2: “Yeni Kullanıcı Hikayeleri Geliştirilebilir Fakat Eski Kullanıcı Hikayeleriyle Karşılaştırılıp Öncelikleri Belirlenmelidir”
Kötü Yaklaşım: “Yeni Kullanıcı Hikayeleri Geliştirmeye Odaklanma”
Zincirinizdeki En Zayıf Halkayı Geçmeye Çalışmayın
Gerçeğe Dönüş
Bölüm Onbeş
Birden Fazla Scrum Takımı’yla Nasıl Çalışıyoruz?
Kaç Scrum Takımı oluşturulacak?
Sanal Takımlar
İdeal Takım Büyüklüğü
Sprint’ler Senkronize mi, Değil mi?
Takım Lideri Rolü Neden Var?
Takımları Nasıl Belirleriz?
Uzmanlık Takımları mı?
Yaklaşım 1: Alanlarına Göre Uzman Takımlar
Yaklaşım 2: Çapraz Takımlar
Sprint’ler Arası Takımlar Yeniden Ayarlanmalı mı, Ayarlanmamalı mı?
Yarı Zamanlı Takım Üyeleri
Scrum’ların Scrum’ını Nasıl Yapıyoruz?
Ürün Seviyesinde Scrum’ların Scrum’ı
Şirket Seviyesinde Scrum’ların Scrum’ı
Günlük Scrum’ları Boş Geçme
Yangın Söndüren Takımlar
Ürün İş Listesi’ni Bölmek ya da Bölmemek?
Strateji 1: Bir Ürün Sahibi ve Bir Ürün İş Listesi
Strateji 2: Bir Ürün Sahibi ve Birden Fazla Ürün İş Listesi
Strateji 3: Birden Fazla Ürün Sahibi ve Her Ürün Sahibi için Bir Ürün İş Listesi
Kod Branch’leme
Birden Fazla Takımla Retrospektif
Bölüm Onaltı
Dağıtık Takımlarla Nasıl Çalıştık?
Üretimin Bazı Aşamalarının Ülke Dışında Gerçekleştirilmesi (Offshoring)
Evden Çalışan Takım Üyeleri
Bölüm Onyedi
Scrum Master Kontrol Listesi
Sprint Başlangıcı
Her gün
Sprint Sonu
Bölüm Onsekiz
Son Sözler
Okuma Önerileri
Yazar Hakkında
Jeff Sutherland’in Önsözü
Takımlar, Scrum’ın 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, Sprint İş Listesi’ne nasıl dönüştürülür? Burn-down grafik nasıl oluşturulur ve takımın hızı nasıl hesaplanır? Henrik’in kitabı başlangıç için güzel bir seçim. Kitap, takımların nasıl iyi Scrum yapabileceğini anlatıyor.
Yatırım desteği almak isteyen takımlar için Scrum’ı iyi yapmak daha önemli hale geliyor. Bir risk sermayesi grubunun Çevik Koçu olarak, grubun, Çevik Pratikleri iyi uygulayan, Çevik şirketlere yatırım yapma hedeflerine erişmelerinde yardımcı olurum. Yani çalıştığım yatırım şirketi, Çevik girişimcileri destekliyor. 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 desteği 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.
Nokia Standartları
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:
- 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 şuradadır; 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ı bileceksiniz. Nokia standartlarında Scrum yapıyor ve yatırım yapılmaya 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
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 Ürün İş Listesi üzerinde nasıl çalıştığını anlatır. Buradan başlayarak diğer bütün öğelerin 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.
Biz Nasıl Yapıyoruz?
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 olacaksınız.
Henrik, iyi pratikleri ve içinde bulunduğu şartları anlatıyor. Bizim siperlerimizde nasıl daha iyi Scrum ve XP yapabileceğimizi öğretiyor.
Mike Cohn,