Sprintlerin yapısında şu mantık esastır. Önümüzdeki 1 ay içinde ne yapacağımızı düşünmek mi daha kolaydır, yoksa bütün bir sene içinde yapılacaklarınızı düşünmek mi? Tabii ki, kısa vadeli bir plan yapıp, sonucu gördükten sonrasını tekrar planlamak çok daha kolaydır. Bu sayede, planlama için ayırdığınız çaba da daha az olacaktır.

Sprintin amacı, Scrum takımının belirli bir hedefe odaklanmasını sağlamaktır. Sprintler, küçük de olsa, bir şeyi başarmak için kullanılır. Ekibin dikkatinin dağılmasına izin vermeden ve kesinti yaşamadan proje hedefine odaklanmalarını sağlar.

Bir şirkette, aynı anda yürüyen farklı projeler olduğunu varsayın. Ekip üyeleri, gün içinde bu farklı projelere dağılmış durumdayken, ortaya çıkan herhangi bir sonuç olmayacaktır. Scrum yaklaşımında, ekip üyeleri tek bir projeye odaklanır ve en azından, küçük de olsa, bir değer üretmek için çalışırlar.

Özetle, çevik yaklaşımlar, işlere başlamaktan ziyade bitirmeye odaklanır. Sprintleri çok küçük projeler olarak görebilirsiniz. Böylece, küçük zaman aralıklarında, müşterinin geri bildirimde bulunabileceği veya doğrudan kullanabileceği sonuçlar ortaya çıkarmak mümkün olacaktır.

Sprint esnasında Scrum takımı, baştan düşünmedikleri şeyleri fark edebilir. Diğer ifadeyle, Scrum Takımı, sprint hedefinin beklediklerinden daha büyük olduğunu anlarlarsa, ürün sahibi ile müzakere ederek, kapsamı azaltabilir, fakat kaliteden asla ödün veremezler. Kapsamın azalması, yeni fark edilen içeriklerin sonraki sprintlerde yapılmak üzere, ürün birikim öğesine eklenmesi anlamına gelecektir.

Benzer bir durum, Sprint süresi için de geçerlidir. Sprint süreleri, 1 aydan uzun olmayacak şekilde belirlenmelidir. Pratik uygulamada, sprint süreleri genellikle 2 hafta olarak tercih edilir. 2 haftalık döngülerle, uygulamaya konulma potansiyeli olan çıktılara ulaşmak, proje içinde bir rutin oluşturulmasını kolaylaştıracaktır.

Eğer sprint hedefinin, beklenenden daha büyük olduğu anlaşılırsa, sprint süresi uzatılmaz. Artan kapsam içeriği, sonraki sprintlere aktarılmak üzere ürün birikim öğesi olarak kaydedilir.

Sprint süresinin 2 hafta olması zorunlu değildir. Farklı sprint süreleri, proje boyunca kullanılabilir. Scrum ekibi ve ürün sahibi arasındaki müzakereler çerçevesinde, sprint süresine karar verilebilir.

Bununla birlikte, büyük bir projede farklı Scrum takımlarının, farklı sprint süreleri kullandığını düşünün. Birbirine entegre edilmesi gereken çıktıların, farklı zamanlarda üretilmesi proje ilerlemesinde düzensizlik yaratacaktır. Buna karşılık, ekiplerin ortak bir sprint süresi üzerinde anlaşarak sprintleri yürütmeleri, ekipler arasında senkronize çalışma şekli yaratacaktır.

17- Zaman Kutusu Nedir?

Scrum’da, zaman kutusu bir etkinliğin maksimum süresini ifade eder.

Örneğin, sprint planlama toplantısını ele alalım. Bu etkinlik, bir aylık sprint için 8 saate kadar zamanlanmış bir kutudur.

Scrum takımı, sprinti planlamak için tam olarak 8 saati kullanabilir. Eğer Scrum takımı toplantının amacına 6 saatte ulaşabilirse, bu çok daha iyi bir şeydir.

Hedeflenen sonuca ulaşılır ulaşılmaz sprint planalama etkinliği sona erer. Bekleyerek zaman kaybetmek için hiçbir sebep yoktur. Scrum, zaman ve kaynak israfını azaltmayı hedefler.

Scrum ekibinin zaman kutusunu aşmasına izin verilmez. Scrum ustası, Scrum Takımına zaman kutularının neden önemli olduğu ve zamanlarının nasıl daha iyi yönetileceği konusunda koçluk yapmalıdır.

Zaman kutuları neden önemlidir? Bunu bir örnekle açıklamaya çalışalım. Kısa süreliğine şehir dışına yolculuğa çıkacağınızı varsayın. 1 veya 2 gün için yapacağınız yolculuk için, hazırlık sürenizi düşünün. 1 günlük yolculuk için yanınıza alacağınız çanta küçüktür ve onu hazırlamak için yarım saat yeterli olacaktır. Buna karşılık, 1 haftalık şehir dışı yolculuğu için, bir valiz hazırlarken daha fazla zaman ayırırsınız. Çok daha uzun yolculuklar içinse bir kaç valiz hazırlamanız gerekeceğinden, hazırlık süreniz daha fazla olacaktır.

Zaman kutuları böyle çalışır. Ne kadar uzak geleceği planlamanız gerekiyorsa, ayırmanız gereken zaman da artar. Buna karşılık, planlamayla fazla zaman kaybedip, işlerin ilerlemesine de engel olmamanız gerekir. Örneğin, valizleri hazırlamaya gereğinden fazla zaman ayırırsanız, bu sefer de uçağı kaçırırsınız.

Scrum’da farklı etkinlikler için zaman kutularının olduğunu ileriki videolarımızda göreceğiz.

Özetlemek gerekirse, bir zaman kutusu bir etkinliğin minimum süresini değil, maksimum süresini ifade eder.

Her türlü etkinlik, etkinliğin amacına ulaşıldığı sürece, zaman kutusu sona ermeden sonlandırılabilir. Fakat, etkinliğin zaman kutusunu aşmasına izin verilmez.

Bu durum, sprintin kendisi hariç, tüm etkinlikler için geçerlidir. Sprint, özel bir durumdur. Planlanan işi, sprintin süresi bitmeden tamamlasanız bile, sprint daha erken bitmez. Bunun sebebi, oluşturmaya çalıştığımız rutinin bozulmasını engellemektir. Fazladan zamanınız kalmışsa eğer, ürün birikim listesinden daha fazla iş alıp, sprinte devam edersiniz. Ancak bu durum, çok nadiren görülür.

14- “Tamamlandının Tanımı” Ne Zaman Hazırlanır?

Scrum Takımı, Tamamlandının Tanımını ne zaman hazırlamalıdır? Scrum Kılavuzu bununla ilgili herhangi bir bilgi vermez, sadece bunun var olması gerektiğini ifade eder.

Bunun nedeni, Scrum’ın bir çerçeve olmasıdır. Adım adım ne yapmanız gerektiğini açıklayan bir metodoloji değildir.

Peki, bu durumda, Tamamlandının Tanımı ne zaman oluşturulmalıdır? Cevap, ne zaman isterseniz.

Çoğu zaman, insanlar her şeyin Scrum etkinliklerinden birinde olması gerektiğini düşünür ve bu doğru değildir.

Scrum Takımı, kendi içinde belirsizlikleri giderecek şekilde farklı toplantılar yapabilir. Bu, Scrum tarafından yasaklanmış değildir.

Scrum Takımının, ilk Sprint başlamadan önce Tamamlandının Tanımının ilk versiyonunu hazırlanmasında hiçbir sakınca yoktur. İlk hali, mükemmel veya nihai olmak zorunda değildir.

Zamanla ihtiyaçlar şekillendikçe veya kalite sorunları yaşandıkça, tamamlandının tanımı da gelişir. Özellikle, Retrospektif toplantılarında ekip deneyimlerini paylaşarak, Tamamlandının Tanımını iyileştirmek için önerilerde bulunabilirler.

Pratik açıdan bakıldığında, zorunlu olmadıkça, sprintin ortasında Tamamlandının Tanımını değiştirmek çok tercih edilen bir yöntem değildir. Bunu bir oyunun kurallarını oyun başladıktan sonra değiştirmek gibi düşünebilirsiniz. Kurallar, oyun başlamadan önce belirlenir. Eğer istenmeyen bir sonuç ile karşılaşılırsa, kurallar, oyun tekrar başlamadan önce oyuncular tarafından konuşulur, anlaşmaya varılır ve oyun ondan sonra başlar.

Tamamlandının Tanımını Sprint’in ortasında değiştirmek tahmin değerlerini ve tamamlandığı düşünülen işleri olumsuz etkileyebilir.

Video için Youtube kanalımı ziyaret edebilirsiniz.

Eğitimlerimiz için İstanbul Kurumsal Gelişim’in Web Sitesini Ziyaret Edebilirsiniz.

Youtube Üzerindeki Videolu Eğitimleri Buradan İnceleyebilirsiniz.

UDEMY Eğitimlerim

13- “Tamamlandının Tanımı” Kavramına Detaylı Bakış

Bu derste, tamamlandının tanımı ifadesine biraz daha detaylı göz atacağız. Bir önceki videomuzda “Başlangıç Sayfası Oluşturma” öğesi için kabul kriterlerini tanımlamıştık.

Burada gördüğünüz ifadeler ise “Başlangıç Sayfası Oluşturma” adlı ürün birikim öğesi için daha detaylı hazırlanmış ve kriterleri gösteren bir örnektir. Yazılanların doğruluğu veya detay seviyesi önemli değildir. Bu örnek, yazılımla ilgili olduğu için, ekranda göreceğiniz ifadeler, bazılarınız için anlamsız olabilir. Bu ifadelerin sadece bir örnek olduğunu dersimiz boyunca unutmayınız.

Öncelikle, tamamlandının tanımı bir kontrol listesi gibi görünse de, Scrum literatürü içinde kontrol listesi ifadesi kullanılmaz. Bu durumu, doktorların veya avukatların kullandığı özel kelimeler gibi düşünebilirsiniz. Her disiplinin kendine özel kavramlarının olması normaldir. Önemli olan bu kavram yapısını bilmek ve diğer meslektaşlarla aynı dili konuşabilmektir.

Konumuza dönersek; bir ürün birikim öğesinin tamamlanmış olarak kabul edilmesi için aşağıdaki kriterlere uyması gerektiği gözükmektedir.

Bu listede ilk maddeye baktığımızda “Kabul Kriterlerinde belirtilen şartların sağlanması” ifadesi gözükmektedir. Bir önceki dersimizde, bu maddeler hakkında örnekler paylaşmıştık. Bu kriterler, genellikle ürünün nasıl gözükeceğini içeren özelliklerdir. Kabul kriterlerinin neler olduğunu görmek için 12.video olan Artırım ve Tamamlandının Tanımı adlı videoyu izlemenizi tavsiye ederiz.

Şu an ekranımızda ise ürünün etkin çalışabilmesi için uyulması gereken farklı kriterlerden de bahsedilmiştir. Bu kriterler, ürün sahibinin bilemeyeceği kriterler olabilir. Bu yüzden, bu kriterler, Scrum takımı tarafından hazırlanır.

Örneğin, hazırlanan kodun, uzman bir geliştirici tarafından gözden geçirilmesi kriteri, daha sonra oluşabilecek kusurları engelleyebilir ve deneyimsiz olan geliştirme ekibinin yeni şeyler öğrenmesini sağlayabilir.

Teknik dokümanın hazırlanmış olması ifadesi, ilgili sayfanın bilgi akışı veya süreç akışını gösteren içerikler olabilir. Bu bilgiler, baştan belgelenmediği takdirde, ve sistemin zamanla büyümesi durumunda, sistemin kontrolü imkansız hâle gelebilir.

Birim testinin geçmesi, hazırlanan fonksiyonun doğru çalışıp, çalışmadığını test etmek ve onaylamak iken, kabul testinden geçmek sistemin bir bütün olarak kabul edilebilir olmasıyla ilgili testlerdir.

Sistemin farklı web tarayıcıları üzerinden test edilmesi ve o tarayıcılarda da sorunsuz çalışması bir başka kriter olarak gözükmektedir. Benzer bir değerlendirme, mobil cihazlar için uygulanabilir. Oluşturduğumuz giriş sayfasının farklı cep telefonlarının ekranlarında nasıl gözüktüğü bir kabul kriteri olabilir.

Bütün bunlara ek olarak fonksiyonel olmayan gereksinimler altında performans, uygunluk ve güvenlik gibi kriterler tanımlanabilir ve üretilen birikim öğesinin bu kriterleri de sağlayıp, sağlamadığı denetlenmiş olur.

Bütün bu kriterlerin olumlu sonuç vermesi halinde, ilgili birikim öğesi “tamamlandı” olarak kabul edilmiş olacaktır.

Müşteri veya ürün sahibi, Sprint içinde geçen süreyi ve harcanan eforu sadece istenen ürünü üretmek olarak düşünmemelidir. Karmaşık bir projede, burada örnek olarak gözüken kabul kriterlerinin sayısı onlarca olabilir. Bu yüzden, Scrum ekipleri, ortaya çıkaracakları ürün birikim öğesinin bu kriterlere uyup uymadığını test etmek zorundadır. Bir projede, ekipleri acele ettirmek, diğer ifadeyle, az zamanda çok fazla şeyi talep etmek ve ekibe baskı kurmak, kalite kriterlerinin yeterince sağlanmadan ürünün teslim edilmesine sebep olur. Bu da, ortaya çıkan ürünün kalite sorunları yaşamasına, ve ekibin düzeltmeler yapmak için tekrar tekrar ürün üzerinde çalışmasına, neden olur.

12- Artırım ve Tamamlandının Tanımı

Artırım, ürünün yeni bir sürümüdür ve önceki tüm sprintlerden gelen artırımlara eklenir.

Bunu, tamamlanmış önceki tüm işlerin üzerine yerleştirilmiş bir yapı taşı gibi görebilirsiniz.

Geliştiriciler, her sprintte en az bir adet yeni ürün artırımı sağlamak için çalışır.

Her yeni artırım, ürünün geliştirilmiş ve kullanılabilir bir sürümüdür.

Artırımın, müşterinin kullanımına sunulma zamanına, yani yayınlanmasına, sadece ürün sahibi karar verir. Bununla birlikte, artırımın kendisi, test etme, belgeleme ve hatta diğer Scrum ekiplerinin yaptığı işlerle entegre etme gibi, herhangi bir ek çalışmaya ihtiyaç duymayacak şekilde, kullanılabilir olmalıdır.

Bir ürün birikim öğesi tamamlanmış olarak kabul edildiğinde, herkes tamamlanmış ifadesinin ne anlama geldiğini anlamalıdır.

Çoğunlukla “tamamlanmış” ifadesi için kalite yönetiminden bildiğimiz kabul kriterleri referans alınır.

Eğer 7. videoda başlattığımız örnekte, ilk ürün birikim öğemiz “Başlangıç sayfası oluşturmaktı. Sonraki bir videomuzda bu öğe için kullanıcı hikayesi yazmıştık. Bir başka videomuzda ise kabul kriterlerini tanımlamıştık.

Kurumun logosu sayfada gözükmeli.
Marketin bina görseli sayfad gözükmeli.
Şirketin adresi, telefon numarası ve email adresi sayfada gözükmeli.

Yine bir başka videomuzda, ekibin yönlendirmesiyle, ürün sahibi, kabul kriterlerinin içine şu iki maddeyi eklemişti.

Logo dijital olarak çizilmiş olmalıdır.

Binanın fotoğrafları profesyonel olarak çekilmiş olmalıdır.

Tam bu noktada lütfen dikkat. Kabul kriterleri hiç bir zaman subjektif ifadeler içeremez. Dikkat ederseniz, “Profesyonel fotoğraf çekimi” ifadesi bile yoruma açıktır. Bu yüzden, çekilecek fotoğrafların çözünürlüğü sayısal verilerle ifade edilmelidir. Amaç, çıkan sonucun ki bu örnekte çekilen fotoğrafların çözünürlüğü, yoruma açık olmaksızın, test edilebilir ve doğrulanabilir olmalıdır.

Her sprint, kalite planlamayı ve kalite kontrolü kendi içinde barındırır. Scrum ekibi, sprint sonlarında yapacakları retrospektif toplantısında öğrendikleri derslerden yola çıkarak, kaliteyi sürekli artırmanın yollarını arayacaklardır.