Siperden Scrum ve XP Biz Nasıl Yapıyoruz

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

Siperden Scrum ve XP Biz Nasıl Yapıyoruz
Siperden Scrum ve XP Biz Nasıl Yapıyoruz

Kitabı indirebileceğiniz bağlantı: Siperden-Scrum-ve-XP-Biz-Nasıl-Yapıyoruz_V2-1.pdf (1593 indirme)

[pdf-embedder url=”http://www.yilmazcihan.com/wp-content/uploads/2017/03/Siperden-Scrum-ve-XP-Biz-Nasıl-Yapıyoruz.pdf” title=”Siperden Scrum ve XP Biz Nasıl Yapıyoruz”]

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,

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir