Scrum Kılavuzu. Scrum ın Tanımlayıcı Klavuzu: Oyunun Kuralları. Ekim Ken Schwaber ve Jeff Sutherland tarafından geliştirilmiş ve sürdürülmüştür

Transkript

1 Scrum Kılavuzu Scrum ın Tanımlayıcı Klavuzu: Oyunun Kuralları Ekim 2011 Ken Schwaber ve Jeff Sutherland tarafından geliştirilmiş ve sürdürülmüştür

2 İçindekiler Scrum Kılavuzunun Amacı... 3 Scrum - Genel Bakış... 3 Scrum Çerçevesi... 3 Scrum - Teori... 4 Scrum... 5 Scrum Takımı... 5 Ürün Sahibi... 5 Geliştirme Takımı... 6 Süreç Yöneticisi Scrum Master... 6 Scrum Toplantıları... 7 Sprint... 8 Sprint Planlama Toplantısı... 9 Günlük Scrum Toplantısı Sprint Gözden Geçirme Toplantısı Sprint Süreç Gözden Geçirme Toplantısı Scrum Çıktıları Ürün Kapsamı Sprint Kapsamı Ürün Parçası Tamamlandı Kriteri Tanımı Sonuç Teşekkürler Kişiler Tarihçe Çeviri Ken Schwaber ve Jeff Sutherland, Tüm Hakları Saklıdır Sayfa 2

3 Scrum Kılavuzunun Amacı Scrum, karmaşık ürünlerin geliştirilmesi ve sürdürülmesi için tanımlanmış bir çerçevedir. Bu kılavuz Scrum çerçevesinin tanımını içermektedir. Scrum tanımı, Scrum rollerini, toplantılarını, Scrum çıktılarını ve bunları birbirine bağlayan kuralları içermektedir. Scrum, Ken Schwaber ve Jeff Sutherland geliştirilmiştir. Ken Schwaber ve Jeff Sutherland, Scrum Kılavuzu nu bütünüyle desteklemektedirler. Scrum - Genel Bakış Scrum, kişilerin, mümkün olan en yüksek katma değerli ürünleri, üretken ve yaratıcı bir şekilde teslim ederken, karmaşık problemleri de ele aldıkları bir çerçevedir. Scrum ın, Karmaşık değildir. Anlaşılması kolaydır. Uzmanlaşması son derece zordur. Scrum, 1990 ların başlarından beri, karmaşık ürün geliştirme yönetimi için kullanılan bir süreç çerçevesidir. Scrum, ürün geliştirmek için bir teknik veya süreç değildir; aksine, içerisinde çeşitli teknikleri ve süreçleri uygulayabileceğiniz bir çerçevedir. Scrum, ürün yönetimi ve ürün geliştirme pratiklerinizin etkinliğini ortaya çıkarır ve böylece pratiklerinizi geliştirmenize olanak sağlar. Scrum Çerçevesi Scrum çerçevesi, Scrum Takımları ve takımla ilgili rolleri, toplantıları, Scrum çıktılarını ve kurallarını içermektedir. Çerçevedeki her bir bileşen, belirli bir amaca hizmet etmektedir ve Scrum ın başarısı ve kullanımı için gereklidir. Scrum ın kullanımına yönelik özel stratejiler değişmektedir ve kılavuz harici kaynaklarda tanımlanmaktadır. Scrum kuralları, toplantıları, rolleri ve çıktıları birbirine bağlar; bunlar arasındaki ilişkileri ve etkileşimleri yönetir. Bu kurallar, dokümanın ileriki bölümlerinde tanımlanmıştır Ken Schwaber ve Jeff Sutherland, Tüm Hakları Saklıdır Sayfa 3

4 Scrum - Teori Scrum, deneye dayalı bir süreç kontrol teorisi (deneycilik (ampirizm)) üzerine kurgulanmıştır. Deneycilik, bilginin deneyimle ve bilinenlerin temel alınarak kararlar verilmesiyle kazanılabileceğini öne süren bir görüştür. Scrum, tahmin edilebilirliği optimize etmek ve riski kontrol etmek için yinelemeli (iterative) ve artımlı (incremental) bir yaklaşım kullanır. Deneye dayalı süreç kontrolü uygulamaları üç temel prensip üzerine kuruludur: Şeffaflık, Denetim ve Adaptasyon. Şeffaflık Süreç içerisindeki önemli safhalar, çıktılardan sorumlu olan herkes tarafından görünür olmalıdır. Şeffaflık prensibi, süreç içerisindeki bu safhaların ortak bir standarda göre tanımlanmasını gerektirir. Bu sayede gözlemcilerin ne gördüğü konusunda ortak bir anlayış oluşturulmuş olur. Örnek vermek gerekirse; Ekip içerisindeki tüm katılımcılar ortak bir süreç dili kullanmalıdır. İşi yapan ve işi kabul eden kişiler ortak bir Tamamlandı 1 kriterinde anlaşmış olmalıdır. Denetim Tutarsızlıkların belirlenmesi için, Scrum çıktıların ve sürecinin Scrum kullanıcıları tarafından sıklıkla denetlenmesi gerekmektedir. Denetim işlemlerinin yapılan işin önüne geçmemesi için, denetim aralıkları iyi ayarlanmalıdır. Denetimler, tecrübeli denetçiler tarafından işin belli noktalarında özenle gerçekleştirildiği zaman, çok yararlı olmaktadır. Adaptasyon Bir denetçinin, sürecin bir veya daha fazla bölümünün belirlenen limitler dışına çıktığını ve istenileni tam olarak karşılayamadığını belirlemesi durumunda, ilgili işlemin ya da işlenen materyalin düzeltilmesi gerekmektedir. Düzeltme işleminin, ileride ortaya çıkabilecek büyük sapmaları engellemek amacıyla, mümkün olan en kısa sürede yapılması zorunludur. Scrum, denetim ve adaptasyon prensipleri için 4 temel fırsat tavsiye etmektedir, bu fırsatlar dokümanın Scrum Toplantıları bölümünde tanımlanmıştır. Scrum Planlama Toplantısı (Sprint Planning Meeting) Günlük Scrum Toplantıları (Daily Scrum Meetings) Sprint Gözden Geçirme Toplantısı (Sprint Review Meeting) Sprint Süreç İyileştirme Toplantısı (Sprint Retrospective Meeting) Ken Schwaber ve Jeff Sutherland, Tüm Hakları Saklıdır Sayfa 4

5 Scrum Scrum, karmaşık ürün geliştirme işlemini destekleyen bir çerçevedir. Bu çerçeve, Scrum Takımlarını ve ilgili rolleri, toplantıları, süreç çıktılarını ve kuralları içermektedir. Çerçevedeki her bir bileşen, belirli bir amaca hizmet etmektedir ve Scrum ın başarısı ve kullanımı için gereklidir. Scrum Takımı Scrum Takımı, bir Ürün Sahibi, Geliştirme Takımı ve bir Süreç Yöneticisi içermektedir. Scrum Takımları, kendi kendini organize olabilmelidir ve farklı disiplinlerden (çapraz fonksiyonel) bireyler içermelidir. Kendi kendine organize olan takımlar, ekip dışındaki kişiler tarafından yönlendirilmek yerine, işlerini en iyi nasıl gerçekleştirebileceklerini kendileri seçerler. Çapraz fonksiyonel takımlar, ekip dışındaki kişilerden bağımsız olarak, görevlerini yerine getirebilecek bütün yetkinliklere sahiptirler. Scrum ın önerdiği bu takım yapısı esneklik, yaratıcılık ve verimliliği en iyi duruma getirmek için tasarlanmıştır. Scrum Takımları, ürünlerini, yinelemeli ve artımlı bir yöntemle teslim ederler ve bu sayede geri bildirim fırsatlarını maksimuma çıkarırlar. Ürünün artımlı olarak sunulması, ürünün çalışan bir sürümünün, her zaman mevcut olmasını sağlar. Ürün Sahibi Ürün Sahibi, Geliştirme Takımı tarafından geliştirilen işin ve ürünlerin değerini maksimuma çıkarmaktan sorumludur. Bu işin nasıl yapılacağı, ürünü geliştiren organizasyonlara, Scrum Takımlarına ve bireylere göre değişiklik gösterebilir. Ürün Sahibi, geliştirilecek olan Ürünün Kapsamının (Product Backlog) yönetiminden sorumlu olan tek kişidir. Ürün Kapsamının yönetimi şu sorumlulukları içermektedir: Ürün Kapsamındaki maddelerin net bir şekilde ifade edilmesi Hedeflerin ve görevlerin en iyi şekilde gerçekleştirilmesi için Ürün Kapsamındaki maddelerin sıralanması Geliştirme Takımı tarafından gerçekleştirilen işin değerini güvence altına almak Ürün Kapsamının, net, şeffaf ve Geliştirme Takımının bir sonraki aşamada ne üzerinde çalışacağını gösterecek şekilde olmasını güvence altına almak Ürün Kapsamındaki her bir maddenin Geliştirme Takımı tarafından ihtiyaç duyulan seviyede anlaşılmasını sağlamak Ürün Sahibi, yukarıda bahsedilen işleri kendisi yapabilir ya da Geliştirme Takımının yapmasını sağlayabilir. Fakat her iki durumda da bu işlerin sorumluluğu Ürün Sahibindedir. Ürün Sahibi grup değil, bir kişidir. Ürün Sahibi, Ürün Kapsamında bir grubun isteklerini temsil edebilir, ancak kapsamdaki bir maddenin önceliğinin değiştirilmesi için grubun, Ürün Sahibini ikna etmesi gerekmektedir Ken Schwaber ve Jeff Sutherland, Tüm Hakları Saklıdır Sayfa 5

6 Ürün Sahibinin başarılı olabilmesi için, organizasyonun tamamı bu kişinin kararlarına saygılı olmalıdır. Ürün Sahibinin kararları, Ürün Kapsamının içeriğinde ve maddelerin sıralanmasında görülebilir. Ürün Sahibi haricinde kimse, Geliştirme Takımına farklı bir gereksinim grubu üzerinde çalışmasını söyleyemez ve Geliştirme Takımı, Ürün Sahibi haricindeki kimsenin yönlendirmesi ile hareket edemez. Geliştirme Takımı Geliştirme Takımı, her iterasyon sonunda kullanılabilir bir ürün ortaya çıkaran kişilerden oluşan gruptur. Bu grup, iterasyon içerisinde geliştirilen ve üretilen bütün çıktılardan sorumludur. Geliştirme Takımları, kendi kendilerine organize olmalıdırlar ve işlerin nasıl yapılacağını kendileri belirlemelidirler. Bu yöntemle Geliştirme Takımı arasındaki sinerji oluşturulmuş olur. Bu sinerji takımın etkinliğini ve verimliliğini arttırır. Geliştirme takımlarının genel özellikleri aşağıdaki gibidir: Geliştirme Takımları kendi kendilerine organize olurlar. Süreç Yöneticileri (Scrum Master) dahil hiç kimse takıma işin nasıl yapılacağını söylememelidir. Geliştirme Takımları, işin yapılması için gerekli yetkinliklere sahip çapraz fonksiyonel bireylerden oluşmalıdır. Geliştirme Takımı içerisindeki bireylerin Geliştirici haricinde hiçbir unvanı olmamalıdır. Takım üyelerinin biri diğerinden daha fazla yetki ile donatılmamalıdır. Bu kural esnetilemez ve değiştirilemez. Geliştirme Takımı üyeleri belirli alanlarda özelleşmiş yetkinliklere sahip olabilirler ancak ürünle ilgili sorumluluk bütün Geliştirme Takımına aittir. Geliştirme Takımının Büyüklüğü Geliştirme Takımları, çıktı üretebilecek kadar büyük, çevik olabilecek kadar küçük olmalıdır. 3 kişiden az üyeli takımlarda etkileşim azalmakta, bunun sonucu olarak da üretkenlik azalmaktadır. Küçük Geliştirme Takımları Sprint sırasında gerekli yetkinliği sağlamakta sıkıntı yaşayabilirler; bu durum da ürünün sunulmasında sorun yaratabilir. 9 kişiden fazla üyeli takımlarda ise koordinasyon ihtiyacı oldukça fazladır. Bu nedenle takımların en az 3 en fazla 9 kişiden oluşması önerilmektedir. Ürün Sahibi ve Süreç Yöneticisi bu sayıya dahil değildir. Süreç Yöneticisi Scrum Master Süreç Yöneticisi, sürecin anlaşılmasından ve kurallara uygun işletilip işletilmediğinin kontrolünden sorumlu kişidir. Süreç yöneticileri bunu süreç teorisinin, pratiklerinin ve kurallarının uygulanmasını takip ederek sağlarlar. Bu roldeki kişiler, Geliştirme Takımı na hizmetkar-lider (servant leader) olarak hizmet etmelidir. Süreç Yöneticisi, takım dışında kalan kişilere sürecin anlatılmasından sorumludur. Ayrıca takım dışında kalan kişilere, takımla olan etkileşimlerinin hangilerinin takıma faydalı olduğunu, hangilerinin ise takımın işleyişini yavaşlattığını belirtmek sorumluluğuna da sahiptir. Süreç Yöneticisi, bu etkileşimleri düzenlemeye çalışarak, takımın en rahat şekilde çalışmasını sağlamalıdır Ken Schwaber ve Jeff Sutherland, Tüm Hakları Saklıdır Sayfa 6

7 Süreç Yöneticisi nin Ürün Sahibi ne Hizmeti Süreç Yöneticisi, Ürün Sahibine aşağıdaki şekillerde hizmet vermelidir: Ürün Kapsamının etkin yönetimi konusunda pratik teknikleri bulmalıdır. Vizyonun, hedeflerin ve Ürün Kapsamındaki maddelerin Geliştirme Takımına açık ve anlaşılır bir şekilde aktarılması konusunda yardımcı olmalıdır. Ürün Kapsamının açık ve kesin ifadeler içerecek şekilde oluşturulmasında yardımcı olmalıdır. Uzun dönemli ürün planlaması konusunda yardımcı olmalıdır. Çeviklik kavramının anlaşılması ve uygulanması konusunda destek olmalıdır. Süreçle ilgili aksiyonların (toplantılar vb.) işletilmesi konusunda istekte bulunulması durumunda yardımcı olmalıdır. Süreç Yöneticisi nin Geliştirme Takımı na Hizmeti Süreç Yöneticisi, Geliştirme Takımına aşağıdaki şekillerde hizmet vermelidir: Geliştirme Takımına kendi kendine organizasyon ve çapraz fonksiyonel olma konusunda rehberlik etmelidir. Yüksek kaliteli ürün geliştirilmesi için Geliştirme Takımını eğitmeli ve takıma liderlik etmelidir. Geliştirme Takımının ilerlemesini sağlamak için, ortaya çıkan problemleri çözmelidir. Süreçle ilgili aksiyonların (toplantılar vb.) işletilmesi konusunda istekte bulunulması durumunda yardımcı olmalıdır. Süreç Yöneticisi nin Organizasyon a Hizmeti Süreç Yöneticisi, şirket veya kurum organizasyonuna aşağıdaki şekillerde hizmet vermelidir: Scrum metodolojisinin uyumunun sağlanması için, organizasyona liderlik ve rehberlik yapmalıdır. Organizasyon içerisinde Scrum uygulamalarını planlamalıdır. Scrum ın ve deneye dayalı ürün geliştirme yöntemlerinin anlaşılması ve kabul edilmesi için organizasyonda yer alan çalışanlara ve diğer paydaşlara yardım etmelidir. Organizasyonel seviyede Geliştirme Takımının üretkenliğini arttıracak değişiklikler yapılması için öncülük etmelidir. Organizasyon seviyesinde Scrum uygulamalarının etkinliğini arttırmak için, diğer Süreç Yöneticileri ile birlikte çalışmalıdır. Scrum Toplantıları Scrum da düzeni sağlamak ve tanımlanmamış diğer toplantılara ihtiyacı azaltmak için, kuralları belirlenmiş aktiviteler (toplantılar) kullanılmaktadır. Scrum, zaman kısıtlaması olan, yani maksimum süresi olan aktiviteler tanımlamıştır. Bu durum, planlama sürecinde gereksiz zaman harcamadan, uygun bir zaman dilimi içerisinde planlama yapılmasını sağlamaktadır Ken Schwaber ve Jeff Sutherland, Tüm Hakları Saklıdır Sayfa 7

8 Diğer aktiviteler için kapsayıcı görevi gören Sprint hariç, Scrum da tanımlı her bir süreç resmi bir denetleme ve adaptasyon fırsatıdır. Bu aktiviteler, kritik şeffaflık ve denetime olanak sağlamak için özellikle tasarlanmıştır. Bu aktivitelerden herhangi birisinin uygulanmaması şeffaflığın azalmasına, denetim ve adaptasyon fırsatının kaçırılmasına sebep olur. Sprint Scrum ın kalbi olan Sprint, maksimum 1 takvim ayı veya Tamamlandı kriterine uyan, kullanılabilir ve mümkünse yayınlanabilir bir ürün parçası geliştirilebilecek daha az bir süre ile sınırlandırılmıştır. Sprintler, bir geliştirme süresince tutarlı sürelere sahip olmalıdır. Sprintler birbirlerini takip eder ve bir Sprint in sonuçlanmasının hemen ardından yeni bir Sprint başlar. Sprintler, Sprint Planlama Toplantısı, Günlük Scrum Toplantıları, geliştirme çalışması, Sprint Gözden Geçirme Toplantısı ve Sprint Süreç İyileştirme Toplantısı ndan oluşmaktadır. Sprint süresince: Sprint amacını etkileyebilecek hiçbir değişiklik yapılmaz. Geliştirme Takımı nın yapısı sabit kalır. Kalite hedefleri azaltılamaz. Yapılacak iş ile ilgili bilgiler arttıkça, Ürün sahibi ve Geliştirme Takımı, kapsama netlik kazandırabilir ve kapsam konusunda tekrar müzakere yapabilirler. Her Sprint, süresi 1 takvim ayından fazla olmayan bir proje olarak değerlendirilebilir. Sprintler, projeler gibi, bir şeyi sonuçlandırmak için kullanılır. Her Sprint in ne geliştirileceğine dair bir tanımı, bir tasarımı, geliştirilecek ürüne rehberlik edecek esnek bir planı, çalışma süreci ve sonucunda ortaya çıkan ürünü vardır. Sprintler bir takvim ayı ile sınırlandırılmıştır. Sprint süresi çok uzun olduğu zaman, geliştirilecek ürünün tanımı değişebilir, karmaşıklık ortaya çıkabilir ve risk artabilir. Sprintler, en az her takvim ayında bir hedefe doğru ilerleme sürecinde denetim ve uyum sağlayarak, öngörülebilirliği sağlar. Sprintler aynı zamanda riski 1 takvim ayı maliyeti ile limitler. Bir Sprint i İptal Etmek Sprintler, maksimum süresi tamamlanmadan iptal edilebilir. Ürün Sahibi; Geliştirme Takımı, Süreç Yöneticisi veya diğer paydaşların etkisi altında bulunmasına rağmen, bir Sprint i iptal etme yetkisi sadece Ürün Sahibi ne aittir. Mevcut şartlar altında belirlenen amacın eğer bir katma değer sağlamayacağı değerlendirilirse, Sprint iptal edilmelidir. Bu durum şirketin hedeflerinde, pazar veya teknoloji şartlarında bir değişiklik olması ile ortaya çıkabilir. Genel olarak, mevcut şartlar altında Sprint e devam etmek artık bir anlam ifade etmiyorsa, Sprint iptal edilmelidir. Ancak Sprint süresinin kısa olması nedeniyle, bir Sprint in iptal edilmesi nadiren anlam ifade etmektedir Ken Schwaber ve Jeff Sutherland, Tüm Hakları Saklıdır Sayfa 8

9 Bir Sprint iptal edildiğinde, bitirilen ve Tamamlandı kriterine uyan Ürün Kapsamı maddeleri gözden geçirilir. Eğer yapılan çalışma yayınlanabilir durumda ise, Ürün Sahibi genellikle kabul eder. Tüm tamamlanmamış Ürün Kapsamı maddeleri için tekrar tahminleme yapılır ve bu maddeler Ürün Kapsamına tekrar yerleştirilir. Bu maddeler üzerinde yapılan çalışma hızla değer kaybeder ve bu maddeler üzerinde sıklıkla tahmin yapılmalıdır. Başka bir Sprint başlatmak için, Sprint Planlama Toplantısı düzenlenmesi gerektiğinden, Sprint in iptal edilme durumu kaynakları tüketir. Sprint iptalleri genellikle Scrum takımları için sarsıcı bir durumdur ve çok nadirdir. Sprint Planlama Toplantısı Sprint Planlama Toplantısı, Sprint süresince yapılacak olan işlerin planladığı toplantıdır. Bu plan bütün Scrum takımının katılımı ile hazırlanmalıdır. 1 aylık Sprintler için önerilen maksimum toplantı süresi 8 saattir. Daha kısa süreli Sprintler için bu toplantının süresi oransal olarak daha kısadır. Örneğin 2 haftalık Sprintler için bu toplantıların süresi maksimum 4 saat olmalıdır. Sprint Planlama Toplantıları iki aşama içermektedir. Her bir aşama toplantı süresinin en fazla yarısı kadar sürdürülür. Bu iki aşama sırasıyla şu iki soruya cevap verecek şekilde tasarlanmıştır: Planlanan Sprintte hangi yetenekler ve fonksiyonlar geliştirilecektir? Belirlenen yetenekler ve fonksiyonlar nasıl geliştirilecektir? Bölüm 1: Hangi Yetenekler ve Fonksiyonlar Geliştirilecektir? Bu bölümde Geliştirme Takımı, geliştirilecek yeteneklerle ilgili tahminler yapmak için çalışır. Ürün Sahibi, sıralanmış Ürün Kapsamını Geliştirme Takımı na sunar ve bütün Scrum Takımı Ürün Kapsamı üzerinde birlikte çalışarak, kapsamı net ve karışıklığa mahal vermeyecek şekilde anlamaya çalışmalıdır. Bu toplantıda Ürün Kapsamı, eğer varsa bir önceki Sprintte geliştirilmiş ve dağıtımı gerçekleşmiş çalışan ürün, Geliştirme Takımının bu Sprintte ki kapasitesi ve Geliştirme Takımının bir önceki Sprintte göstermiş olduğu performans kayıtları girdi olarak kullanılır. Ürün Kapsamından ne kadar maddenin seçileceği tamamen Geliştirme Takımına aittir. Sadece Geliştirme Takımı, gelecek Sprintte ne kadar işi yapabileceğine karar vermelidir. Tahminler yapılıp, geliştirilecek maddeler seçildikten sonra, bütün rollerin ortak kararı ile Sprint Hedefi tanımlanır. Sprint Hedefi, Ürün Kapsamı geliştirilirken Sprint içerisinde yerine getirilmesi gereken hedeftir ve Geliştirme Takımı na neden bu yeteneklerin geliştirildiği konusunda yol gösterici olması amacı ile yaratılır. Bölüm 2: Seçilmiş Yetenek ve Fonksiyonlar Nasıl Geliştirilecektir? Sprint süresince yapılacak işler seçildikten sonra, Geliştirme Takımı seçilen fonksiyonları nasıl Tamamlandı kriterine uyan bir ürün parçası yapılacağına karar verir. Seçilen Ürün Kapsamı maddelerine, bu maddelerle ilgili teslim planı eklenerek oluşturulan çıktıya Sprint Kapsamı adı verilir Ken Schwaber ve Jeff Sutherland, Tüm Hakları Saklıdır Sayfa 9

10 Geliştirme Takımı genellikle sistemi ve Ürün Kapsamını çalışan bir ürün parçasına dönüştürecek tasarımı yaparak çalışmaya başlar. Yapılacak çalışma farklı büyüklüklere veya farklı zaman tahminlerine sahip olabilir. Ancak, Sprint Planlama Toplantısı süresince, Geliştirme Takımı gelecek Sprintte yapabileceğine inandığı yeterli miktardaki iş için tahmin ve planlama yapar. Bu toplantının sonunda, Sprint in ilk günleri için planlanan işler, Geliştirme Takımı tarafından 1 gün veya daha az birimlere parçalanır. Geliştirme Takımı kendi kendine organize olarak işleri üstlenmeye ve ilgili işlerle ilgili geliştirme sorumluluklarını, bu toplantıda veya gerektiğinde Sprint süresince üstlenmeye başlar. Ürün Sahibi, Ürün Kapsamından seçilen maddeleri detaylandırmak ve pazarlık yapılmasına yardım etmek amacıyla, Sprint Planlama Toplantısı nın ikinci bölümüne de katılabilir. Eğer Geliştirme Takımı, bir işin çok büyük veya çok küçük olduğuna kanaat getirirse, Ürün Sahibi ile tekrar pazarlık ederek, Sprint Kapsamında değişikliğe gidebilir. Ayrıca Geliştirme Takımının ihtiyaç duyması halinde alan bilgisine sahip uzmanlarda bu toplantıya davet edilebilir. Toplantı sonunda Geliştirme Takımı, Ürün Sahibi ne ve Süreç Yöneticisi ne, kendi kendine organize olan bir takım olarak Sprint Hedefinin nasıl gerçekleştirileceğini ve beklenen ürün parçasının nasıl geliştirileceğini anlatabilmelidir. Sprint Hedefi Sprint Hedefi, Geliştirme Takımı na bir Sprint içerisinde geliştirilecek yeteneklerle ile ilgili bir miktar esneklik sağlar. Geliştirme Takımı çalışırken, bu hedef aklındadır. Geliştirme Takımı, Sprint Hedefini yerine getirebilmek için, yetenek ve teknoloji geliştirir. Eğer yapılan çalışma Geliştirme Takımı nın beklentilerinden farklı bir sonuç ortaya çıkarırsa, Geliştirme Takımı ve Ürün Sahibi bir araya gelir, Sprint içerisindeki geliştirilecek olan Sprint kapsamı ile ilgili görüşürler. Sprint Hedefi, geniş görünümde ürün yol haritasındaki bir kilometre taşı olabilir. Günlük Scrum Toplantısı Günlük Scrum Toplantısı, 15 dakikalık zaman sınırlı bir aktivitedir. Amacı, Geliştirme Takımı üyelerinin birbirleri ile senkronize olmalarını sağlamak ve sonraki 24 saat için plan yapmaktır. Bir önceki toplantıdan beri yapılan çalışmaların denetlenmesi ve bir sonraki toplantıdan önce yapılacak çalışmaların tahmin edilmesi ile toplantının amacına ulaşılır. Günlük Scrum Toplantıları, karmaşıklığı azaltmak için her gün aynı yer ve saatte düzenlenir. Toplantı esnasında, her Geliştirme Takımı üyesi aşağıdaki konular hakkında konuşur: Bir önceki toplantıdan sonra hangi işler tamamlandı? Bir sonraki toplantıya kadar hangi işler yapılacak? Yolumuzdaki engeller nelerdir? Ken Schwaber ve Jeff Sutherland, Tüm Hakları Saklıdır Sayfa 10

11 Geliştirme Takımı, Günlük Scrum toplantılarını Sprint Hedefine doğru ilerlemeyi ve Sprint Kapsamındaki işleri tamamlamak için kaydedilen ilerlemenin eğilimini değerlendirmek için kullanır. Günlük Scrum Toplantıları, Geliştirme Takımı nın Sprint hedefine ulaşma ihtimalini en uygun seviyeye getirir. Geliştirme Takımı, sıklıkla Günlük Scrum Toplantısı sonrasında toplanarak geri kalan Sprint çalışmasını tekrar planlar. Geliştirme Takımı, her gün Ürün Sahibi ne ve Süreç Yöneticisi ne, kendi kendine organize olan bir takım olarak hedefin nasıl gerçekleştirileceğini ve beklenen ürün parçasının nasıl geliştirileceğini anlatabilmelidir. Süreç Yöneticisi, Günlük Toplantıların yapılıp, yapılmadığından emin olur. Ancak toplantının yapılması sorumluluğu tamamen Geliştirme Takımına aittir. Süreç Yöneticisi, sadece bu toplantıların 15 dakikalık zaman sınırı içinde tamamlanması konusunda Geliştirme Takımına liderlik yapar. Süreç Yönetici, Günlük Scrum Toplantılarına sadece Geliştirme Takımı üyelerinin katılmasını sağlar. Bu toplantılar durum değerlendirme toplantısı değildir ve sadece Sprint Kapsamında bulunan işleri bir ürün parçası haline getirmek için çalışan Geliştirme Takımı içindir. Günlük Scrum Toplantıları takım arasındaki iletişimi geliştirir, başka toplantılara olan ihtiyacı azaltır, geliştirme safhasının önündeki engellerin tanımlanmasına ve ortadan kaldırılmasına yardımcı olur. Ayrıca Geliştirme Takımının çabuk karar alma yeteneğini geliştirerek, hızlı hareket etmelerine olanak sağlar. Bu toplantıların önemli noktalardan birisi de, Geliştirme Takımının proje ile ilgili bilgi birikimini arttırmasına katkıda bulunmasıdır. Bu toplantılar denetleme ve adaptasyon için anahtar bir toplantıdır. Sprint Gözden Geçirme Toplantısı Sprint Gözden Geçirme Toplantısı, her Sprint sonunda Sprint esnasında üretilen ürün parçasının gözden geçirilmesi ve gerekli durumlarda Ürün Kapsamı nın güncellenmesi için düzenlenir. Sprint Gözden Geçirme Toplantıları sırasında, Scrum Takımı ve diğer paydaşlar Sprint süresince neler yapıldığı konusunda konuşurlar. Toplantı katılımcıları, Sprint süresince gerçekleştirilen işleri ve Ürün kapsamındaki değişiklikleri temel alarak, bir sonraki Sprint te neler yapılacağı konusunda konuşurlar. Bu toplantılara resmi olarak bir hazırlık yapılmaz ve geliştirilen ürün parçası sunulur. Bunun amacı geliştirilen ürün parçası hakkında geri bildirim almak ve işbirliğini arttırmaktır. Sprint Gözden Geçirme Toplantıları, 1 aylık sprintler için 4 saat zaman sınırı olan toplantılardır. Daha kısa Sprintler için oransal olarak daha az zaman içerisinde düzenlenmelidir. Örneğin 2 haftalık Sprintler için 2 saatlik Sprint Gözden Geçirme Toplantısı düzenlenir. Sprint Gözden Geçirme Toplantıları aşağıdaki unsurları içermektedir: Ürün Sahibi nelerin Tamamlandı kriterine uyduğunu ve uymadığını belirler. Geliştirme Takımı, Sprint süresince nelerin iyi gittiğini, hangi problemlerle karşılaşıldığını ve bu problemlerin nasıl çözüldüğünden bahseder. Geliştirme Takımı, geliştirilen ürünün tanıtımını gerçekleştirir ve ilgili soruları yanıtlar Ken Schwaber ve Jeff Sutherland, Tüm Hakları Saklıdır Sayfa 11

12 Ürün Sahibi, Ürün Kapsamını ve Geliştirme Takımının ilerleme durumunu göz önüne alarak, hedeflenen ürüne ulaşılacak zaman tahminini günceller. Bütün grup bir sonraki adımda ne yapılması gerektiği konusunda tartışır. Bu sayede bir sonraki Sprint Planlama Toplantısına değerli bir girdi sağlanmış olur. Sprint Gözden Geçirme Toplantısının sonucu olarak bir sonraki Sprint te seçilmesi muhtemel maddeleri içeren revize edilmiş Ürün Kapsamı ortaya çıkar. Yeni fırsatları karşılamak için Ürün Kapsamı tamamen de değiştirilebilir. Sprint Süreç Gözden Geçirme Toplantısı Sprint Süreç Gözden Geçirme Toplantısı, süreci işleten takımın kendi kendisini değerlendirmesi ve gelecek Sprint te kullanılmak üzere iyileştirme planları hazırlaması için bir fırsattır. Sprint Süreç Gözden Geçirme Toplantısı, Sprint Gözden Geçirme Toplantısı ile bir sonraki Sprint Planlama Toplantısı arasında yapılır. 1 aylık Sprintler için maksimum 3 saat olacak şekilde yapılır. Daha kısa Sprintler için oransal olarak daha kısa olarak düzenlenir. Sprint Süreç Gözden Geçirme Toplantısının amaçları aşağıdaki şekilde sıralanabilir: Bir önceki Sprintte kişiler, ilişkiler, süreç ve araçlar bakımından yaşanan gelişmelerin ortaya çıkarılması ve değerlendirilmesi. İyi yapılan ve gelişmeye açık yönlerin tanımlanması ve önem sırasına göre listelenmesi Takımın işini daha iyi yapabilmesine olanak sağlayacak şekilde, eksik yönlerin iyileştirilmesine yönelik planın hazırlanması Süreç Yöneticisi, diğer takım üyelerini düşüncelerini paylaşması için cesaretlendirir ve geliştirme sürecinin ve uygulanan pratiklerin bir sonraki Sprintte daha etkin ve eğlenceli hale getirilmesi için çaba sarf eder. Sprint Süreç Gözden Geçirme Toplantısı süresince, Scrum Takımı ürün kalitesini Tamamlandı tanımını uygun şekilde adapte ederek, arttıracak yolların planlarını yapar. Sprint Süreç Gözden Geçirme Toplantısı sonunda, Scrum Takımı bir sonraki Sprint te uygulanacak iyileştirmeleri tanımlamış olmalıdır. Bu iyileştirmelerin bir sonraki Sprint te uygulanması, Scrum Takımı nın kendi kendisini denetlemesi ve adaptasyonudur. İyileştirmeler, herhangi bir zamanda uygulanabilir olsa da, Sprint Süreç Gözden Geçirme Toplantıları denetim ve uyum üzerine odaklanmak için resmi bir fırsat sunar. Scrum Çıktıları Scrum çıktıları, iş veya değeri çeşitli yollarla temsil ederler. Bu yollar şeffaflık için yararlıdır, denetim ve adaptasyon için fırsat sağlarlar. Scrum tarafından tanımlanmış çıktılar Scrum takımının Tamamlandı kriterine uyan ürün parçasını başarılı bir şekilde ortaya çıkarabilmesi için gerek duyulan anahtar bilgilerin şeffaflığının arttırılması için özellikle tasarlanmıştır Ken Schwaber ve Jeff Sutherland, Tüm Hakları Saklıdır Sayfa 12

13 Ürün Kapsamı Ürün Kapsamı bir ürün için gerekli olabilecek her şeyi içeren sıralı bir listedir. Ürün Kapsamı ürünle ilgili gereksinimlerin tek kaynağıdır. Ürünün yeteneklerinde değişiklik yapılması istenirse, Ürün Kapsamı değiştirilir. Ürün yöneticisi, Ürün Kapsamının içeriğinden, diğer paydaşların kapsama ulaşabilirliğinden ve gereksinimlerin sıralanmasından sorumludur. Ürün Kapsamı hiç bir zaman tam değildir. İlk üretildiğinde, sadece ilk aşamada bilinen ve çok iyi anlaşılmış gereksinimleri içerir. Ürün geliştirildikçe ve ortam değiştikçe, Ürün Kapsamı da değişir ve gelişir. Ürün Kapsamı dinamiktir, bu sayede geliştirilen ürünün uygun, diğer muadilleri ile yarışabilir ve kullanışlı olmasını sağlar. Ürün Kapsamının bu özellikleri sayesinde müşteriden gelebilecek değişikliklere en çevik şekilde yanıt verilmesi mümkün kılınır. Ürün var olduğu sürece, Ürün Kapsamı da var olur. Ürün Kapsamı, ürünle ilgili bütün fonksiyonları, yetenekleri, gereksinimleri, iyileştirmeleri ve gelecekteki yaygınlaştırmalarda yapılması gereken düzeltmeleri içerir. Ürün Kapsamını oluşturan maddeler; tanım, sıra ve tahmin olacak şekilde 3 alandan oluşmaktadır. Ürün Kapsamı genellikle değer, risk, öncelik ve gereklilik faktörlerine göre sıralanmıştır. En üstte yer alan Ürün Kapsamı maddeleri, acil geliştirme faaliyetlerini yönlendirmektedir. Bir Ürün kapsamı maddesinin yüksek sıralı olması, o maddenin daha kabul edilir olması anlamına gelmektedir. Bu sayede bu maddenin değeri ve kendisi üzerinde uzlaşma sağlanmasına yarar. Yüksek sıralı Ürün Kapsamı maddeleri, düşük sıralı olanlara oranla daha açık ve daha detaylıdır. Sıranın aşağılara inmesi demek, detaylarda azalma demektir. Daha iyi tahminler, daha yüksek anlaşılırlık ve detayların biliniyor olması temel alınarak yapılır. Geliştirme Takımını gelecek Sprint te meşgul edecek Ürün Kapsamı maddeleri, her biri Sprint zaman sınırı içerisinde Tamamlandı kriterine göre geliştirilebilecek küçük parçalara parçalanmıştır. Geliştirme Takımı tarafından bir Sprint içerisinde Tamamlandı kriterine göre geliştirilebilecek Ürün Kapsamı maddeleri, Sprint Planlama toplantılarında seçilmek için Hazır veya Aksiyon Alınabilir olarak kabul edilir. Ürün Kapsamı, bir ürün kullanıldıkça, değer kazandıkça ve pazardan geri bildirim alındıkça genişler ve daha büyük bir liste halini alır. Gereksinimlerin değişimi hiçbir zaman durmaz, bu nedenle Ürün Kapsamı yaşayan bir çıktıdır. Gereksinimlerdeki, pazar şartlarındaki, veya teknolojideki değişimler, Ürün Kapsamı nda da değişimlere neden olabilir. Aynı ürün üzerinde, genellikle birden fazla Scrum takımı çalışır. Ürün ile ilgili gelecek işleri tanımlamak için bir Ürün Kapsamı kullanılır. Bu durumlarda Ürün Kapsamı maddelerine, bu maddenin hangi takım tarafından üstlenildiği bilgisi eklenmelidir. Ürün Kapsamı yönetimi, Ürün Kapsamı maddelerine detaylar eklenmesi, tahminler yapılması ve maddelerin sıralanması olarak tanımlanır. Geliştirme Takımı ve Ürün Sahibi tarafından ortaklaşa yürütülen sürekli bir aktivitedir. Ürün Kapsamı yönetimi süresince, maddeler gözden geçirilir ve Ken Schwaber ve Jeff Sutherland, Tüm Hakları Saklıdır Sayfa 13

14 revize edilir. Ancak, Ürün Kapsamı maddeleri, Ürün Sahibi tarafından veya Ürün Sahibi nin bilgisi dahilinde her zaman güncellenebilir. Ürün Kapsamı yönetimi, Geliştirme Takımı ve Ürün sahibi arasında bir Sprint içerisinde yapılan yarı zamanlı bir aktivitedir. Geliştirme Takımı genellikle Ürün Kapsamı yönetimi aktivitesini yapabilecek alan bilgisine sahiptir. Ürün Kapsamı Yönetiminin nasıl ve ne zaman yapılacağına Scrum Takımı tarafından karar verilir. Ürün Kapsamı Yönetimi aktivitesi genellikle, Geliştirme Takımı nın %10 kapasitesinden fazla zaman almaz. Ürün Kapsamında yer alan maddelerin tüm zaman tahminlerinin yapılmasından Geliştirme Takımı sorumludur. Ürün Sahibi bu tahminler yapılırken, ilgili maddelerin anlaşılması konusunda takıma yardımcı olabilir. Ancak yine de bu konudaki en son karar Geliştirme Takımına aittir. Hedefe Doğru İlerlemenin Gözlenmesi Herhangi bir zamanda, hedefe ulaşmak için kalan çalışma zamanı toplanabilir. Ürün Sahibi, en azından her bir Sprint Gözden Geçirme Toplantısında kalan toplam çalışma zamanını izlemelidir. Ürün Sahibi, daha önceki Sprint Gözden Geçirme Toplantılarındaki kalan çalışma miktarını, hedef ulaşmak için planlanan çalışmayı arzu edilen zamanda tamamlamaya yarayacak ilerlemeyi değerlendirmek için karşılaştırır. Bu bilginin bütün paydaşlar tarafından görünür olması sağlanır. İlerleme ile ilgili tahminler için çeşitli burndown, burnup ve diğer projektif pratikler kullanılır. Bu pratiklerin yararlı olduğu kanıtlanmıştır. Ancak bu pratikler ampirisizmin öneminin yerini almaz. Karmaşık ortamlarda gelecekte ne durumla karşılaşılacağı bilinmez. İleriye dönük kararlar alabilmek için sadece daha önce ne olduğu kullanılabilir. Sprint Kapsamı Sprint Kapsamı, Ürün Kapsamı içerisinden Sprint için seçilmiş ve Sprint hedefini ortaya koyacak ve ürün parçasının teslim edilmesini sağlayacak bir plan içeren maddelerden oluşmaktadır. Sprint Kapsamı, Geliştirme Takımının gelecek ürün parçasında hangi yeteneklerin olacağı ve bu yeteneklerin teslim edilmesi için gereken çalışmalarla ilgili tahminidir. Sprint Kapsamı, Geliştirme Takımı nın Ürün Kapsamı maddelerini Tamamlandı kriterine uyacak şekilde geliştirmek için yapacağı çalışmaları tanımlar. Sprint Kapsamı, Geliştirme Takımı nın Sprint Hedefine ulaşmak için gerekli gördüğü bütün çalışmaları görünür kılar. Sprint Kapsamı, Günlük Scrum Toplantılarında anlaşılabilecek, ilerlemedeki değişikliklerle ilgili yeterli detayları içeren, bir plandır. Geliştirme Takımı, Sprint süresince Sprint Kapsamını değiştirir ve Sprint Kapsamı Sprint süresince ortaya çıkmaya devam eder. Bu durum, Geliştirme Takımı plan dahilinde çalışmaya devam ettikçe ve Sprint Hedefini başarmak için gerekli çalışma hakkında daha çok bilgi edindikçe oluşur. Yeni bir çalışma gerektiğinde, Geliştirme Takımı bunu Sprint Kapsamına ekler. Çalışma gerçekleştirildiğinde veya tamamlandığında, kalan tahmini çalışma güncellenir. Planın herhangi bir maddesi gereksiz görülürse, plandan silinir. Sprint süresince Sprint Kapsamındaki değişiklikler Ken Schwaber ve Jeff Sutherland, Tüm Hakları Saklıdır Sayfa 14

15 sadece Geliştirme Takımı tarafından yapılabilir. Sprint Kapsamı tamamen ve sadece Geliştirme Takımına aittir. Sprint Kapsamı, Sprint süresince Geliştirme Takımı nın gerçekleştirmeyi planladığı çalışmanın gerçek zamanlı bir resmidir ve yüksek derecede görünürdür. Sprint İlerlemesinin Gözlenmesi Sprint süresince herhangi bir noktada, Sprint Kapsamı nda kalan işlere ait süreler toplanabilir. Geliştirme Takımı, Günlük Toplantılarda Sprint Hedefine ulaşmak için kalan süreyi gözlemler. Bu sayede Sprint boyunca Sprint hedefine ulaşmak için gerekli olan işler takip edilir ve Geliştirme Ekibi ilerleme hızını ayarlayabilir. Scrum, Sprint Kapsamında biten işler için harcanan zamanı dikkate almaz. Sadece Sprint Kapsamı ndaki işlerin bitmesi için kalan süre ve iş miktarı göz önüne alınır. Ürün Parçası Scrum da her Sprint sonunda ürünün bir ürün parçası yaratılır. Ürün Parçası, bir Sprint boyunca Ürün Kapsamındaki işlerden tamamlananların toplamıdır ve ürünün potansiyel olarak dağıtımı yapılabilecek bir parçasıdır. Sprint sonunda yaratılan ürün parçası, Scrum Ekibinin Tamamlandı tanımını karşılamalıdır. Scrum da Ürün, koşulan Sprint sayısı arttıkça parçalar halinde büyür. Tamamlandı Kriteri Tanımı Ürün Kapsamındaki bir iş Tamamlandı olarak tanımlandığında, ekipteki herkes bu tanımın ne anlama geldiğini anlamalıdır. Bu tanım, farklı Scrum Takımlarında değişiklik gösterse de ekip içerisinde şeffaflığı sağlamak adına, ortak bir anlayış oluşturulmalıdır. Tamamlandı tanımı ekip içerisinde bir iş ya da ürün parçası tamamlandığında değerlendirmek için kullanılacaktır. Aynı tanım, Sprint Planlama Toplantısı sırasında Geliştirme Takımı nın ne kadar iş seçebileceği konusunda da takımı yönlendirir. Her Sprint in amacı mevcut Tamamlandı tanımına uygun, dağıtımı yapılabilecek yetenekler içeren ürün parçaları inşa etmektir. Geliştirme Takımları, her Sprintte dağıtımı yapılabilecek yetenekler içeren bir ürün parçası inşa eder. Bu ürün parçası, Ürün Sahibinin sağlanan fonksiyonaliteleri hayata geçirmesine imkan verecek şekilde kullanıma hazır olmalıdır. Ayrıca, dağıtımı yapılacak her ürün parçasının, önceki tüm ürün parçaları ile bir arada çalışmasını sağlamak amacıyla bu ürün parçasına ilave olması ve kapsamlı olarak test edilmiş olması gerekmektedir. Scrum Takımı olgunlaştıkça ekip için oluşturulan Tamamlandı tanımı daha yüksek kaliteyi sağlamak için daha zorlu kriterler içerecektir Ken Schwaber ve Jeff Sutherland, Tüm Hakları Saklıdır Sayfa 15

16 Sonuç Scrum ücretsizdir ve temel bilgileri bu kılavuzda sunulmaktadır. Scrum rolleri, eserleri, olayları ve kuralları değişmezdir ve Scrum ın yalnızca belli parçalarının uygulanması mümkün olsa bile, sonuçta uygulanan metodoloji Scrum değildir. Teşekkürler Kişiler Scrum ın gelişmesine katkıda bulunan binlerce insan olmasına rağmen, Scrum ın ilk 10 yılındaki deneylere katılan kişileri ayırmalıyız. İlk önce Jeff McKenna ile çalışan Jeff Sutherland, Mike Smith ve Chris Martin ile çalışan Ken Schwaber vardılar. Daha sonraki yıllarda birçok kişi katkıda bulundu. Onların yardımı olmadan, Scrum bugünkü arıtılmış halini alamazdı. David Starr önemli görüşlerini ve Scrum Klavuzu nun bu sürümünün oluşturulmasında yazı işleri becerilerini sundu. Tarihçe Ken Schwaber ve Jeff Sutherland Scrum ı ilk olarak 1995 yılında OOPSLA konferansında birlikte sundular. Bu sunum, aslında Ken ve Jeff in daha önceki bir kaç yıldaki Scrum uygulamalarında öğrendiklerini belgeledi. Scrum ın tarihçesi uzun kabul edilir. İlk denendiği ve geliştirildiği yerleri onurlandırmak gerekir: Individual, Inc., Fidelity Investments, ve IDX (GE Medical) Scrum Kılavuzu, 20 yıldan fazladır Jeff Sutherland ve Ken Schwaber tarafından geliştirilmiş ve sürdürülmüş Scrum ı belgeler. Diğer kaynaklar, size Scrum çerçevesini tamamlayan kalıpları, süreçleri, görüşleri, kolaylıkları, pratikleri ve araçları sunmaktadır. Çeviri Bu kılavuz Ken Schwaber ve Jeff Sutherland tarafından sağlanan orjinal İngilizce sürümden tercüme edilmiştir. Çeviriye katkıda bulunanlar: ScrumTurkey ekibinden Barış BAL, İbrahim GÜNTAŞ, Mert ÇALIŞKAN, Hakan SÖZER, Mustafa KESKİN, Alp EKŞİOĞLU ve Kerem ÖZEN Ken Schwaber ve Jeff Sutherland, Tüm Hakları Saklıdır Sayfa 16