Scrum Klavuzu

Scrum Klavuzu
Scrum Klavuzu

Scrum Klavuzu

Scrum Klavuzunun Amacı

Scrum, karmaşık ürünlerin geliştirilmesini ve sürdürülmesini gerçekleştirmemizi sağlayan çerçevedir.

Bu rehber Scrum’ın tanımını içerir. Bu tanım, Scrum rolleri, etkinlikleri, artifact’leri ve bunları bir arada tutan kurallardan oluşur.

Scrum, Ken Schwaber ve Jeff Sutherland tarafından geliştirilmiştir. Scrum Klavuzu onlar tarafından yazılmıştır ve desteklenmektedir.

Scrum’ın Tanımı

Scrum, mümkün olan en yüksek değerli ürünlerin verimli ve yaratıcı bir şekilde teslimi yapılırken, kişilerin, karmaşık problemleri çözmesidir. Scrum;

  • Sadedir
  • Anlaması kolaydır
  • Hakim olmak zordur

Scrum 1990’ların başından beri karmaşık ürün geliştirilmesinde kullanılan bir çerçevedir. Scrum, ürün oluşturma için kullanılan bir süreç ya da teknik değildir. Bundan öte içinde çeşitli süreçleri ve teknikleri kullanabileceğiniz bir çerçevedir. Scrum, ürün yönetimi ve geliştirme tekniklerinizin göreceli etkinliğini ortaya çıkarır böylece sizde kendinizi geliştirebilirsiniz.

Scrum yapı olarak, Scrum Takımları’ndan ve onlara atanmış rollerden, etkinliklerden, artifact’lerden ve kurallardan oluşur. Bu çerçeve içindeki her bileşen, belirli bir amaca hizmet eder ve bu bileşenler Scrum’ın başarısı ve devamı için temeldir.

Scrum kuralları, etkinlikleri, rolleri ve artifact’leri bir arada tutar, bunlar arasındaki ilişkileri ve etkileşimleri yönetir. Scrum kuralları, bu dokümanda tanımlanır.

Scrum Teori

Scrum, deneysel süreç kontrol teorisi ya da deneycilik üzerine kurulmuştur. Deneycilik şunu iddia eder; bilgi, tecrübeden gelir ve karar alma işi ne bildiğine dayanır. Scrum, tahmin edilebilirliği optimize etmek ve riski kontrol etmek için ilerlemeli(iterative), artımlı(incremental) bir yaklaşım kullanır.

 

3 sütun, deneysel süreç kontrolünün uygulanmasını ayakta tutar:

Şeffaflık

Sürecin önemli yönleri, sonuçtan sorumlu kişiler tarafından görülebilmelidir. Şeffaflık, bu önemli yönlerin ortak bir standart tarafından tanımlanmasını ve böylece gözlemcilerin gördüklerine dair ortak bir anlayışı paylaşmasına ihtiyaç duyar. Örneğin;

  • Katılımcılar arasında paylaşılan ortak bir dil olmalıdır. Kişiler birbirini anlayabilmelidir, terimlere yabancı kalmamalıdırlar.
  • İşi gerçekleştiren kişiler ve işi kabul eden kişiler ortak bir BİTTİ(DONE) anlayışını paylaşmalıdırlar. Yani bir işin bitişi herkeste aynı şeyi ifade etmelidir. İşi gerçekleştirenler eksikler bırakıp işi tamamladıklarını ifade etmemelidir aynı şekilde bunun tersi geçerlidir.
Gözlem

Scrum kullanıcıları, istenmeyen durumlara karşı Scrum artifact’lerini ve ilerlemeyi sıklıkla gözlemlemelidir. Bu gözlemler işin yapılmasını engelleyecek kadar sık olmamalıdır. Yetenekli kişiler tarafından özenle yapıldığında gözlemler çok yararlıdır.

Adaptasyon

Eğer gözlemci sürecin bir ya da daha fazla açıdan kabul edilebilir limitlerin dışına çıktığına karar verirse, bunun sonucundaki ürün kabul edilemez, süreç ya da ürün adapte edilmelidir. Adaptasyon mümkün olduğunca çabuk yapılır ki bu sapma ilerlemeyip, en aza indirgensin.

Scrum,  bu dokümanın Scrum Etkinlikleri bölümünde tanımladığı gibi, gözlem ve adaptasyon için 4 resmi toplantı belirtir;

Scrum Takımı

Scrum Takımı, Product Owner, Development Team ve Scrum Master’dan oluşur. Scrum Takımları, kendi kendine organize(self-organize) ve çapraz fonksiyonel(cross-functional: buradaki anlamı projeyi geliştirmek için ihtiyaç duyulan farklı alanlardaki -mühendis, pazarlamacı, finansçı, avukat, operasyoncu, insan kaynakları- kişileri kapsayan ve bu projeyi oluşturmak için tüm yeteneklere sahip olan bir takım ve takımın her üyesi kendi işlerinden fazlasını yapmaya gönüllü olmasıdır) bir takımdır. Kendi kendine organize takımlar, takım dışındaki kişiler tarafından yönlendirilmektense işlerini en iyi nasıl başarabileceklerini kendileri belirler. Çapraz fonksiyonel takımlar, takım dışındaki kişilere ihtiyaç duyulmadan işin başarıyla bitirilmesi için gerekli olan tüm yetkinliklere sahiptir. Scrum içindeki takım modeli, esnekliği, yaratıcılığı ve verimliliği en iyi seviye de tutacak şekilde tasarlanır.

Scrum takımları, yineleyerek ve artımlı şekilde ürünleri teslim ederler. DONE olan ürünün artımlı teslimleri sayesinde çalışan ürünün sürümleri her zaman erişilebilirdir.

Product Owner

Product Owner, ürünün ve Development Team’in gerçekleştirdiği işin değerini en yükseğe çıkarmakla sorumludur. Bu işin nasıl yapılacağı kurumlar, Scrum takımları ve bireysel olarak çok çeşitlilik gösterebilir. Product Owner, Product Backlog’u yöneten tek kişidir. Product Backlog yönetimi aşağıdakileri içerir:

Product Owner yukarıdaki işleri yapabilir ya da Development Team’in bunu yapmasını sağlayabilir. Her durumda Product Owner sorumludur.

Product Owner rolü bir kişiden oluşur, bir komiteden değil. Product Owner, Product Backlog’ta bir komitenin isteklerini sunabilir ama Product Backlog’taki maddelerin önceliğini değiştirmek isteyenler Product Owner ile görüşmelidir.

Product Owner’ın başarılı olması için tüm organizasyon onun kararlarına saygı duymalıdır. Product Owner’ın kararları Product Backlog’un içeriğinde ve sıralanmasında görülebilir. Product Owner haricinde hiç kimse, Development Team’e farklı bir iş üzerinde çalışmasını söyleyemez ve Development Team başka birinin söylemesiyle hareket edemez.

Development Team

Development Team, her Sprint sonunda DONE ürünün potansiyel sürümünü ulaştırma işini yapan profesyonellerden oluşur. Sadece Development Team üyeleri yeni sürüm oluşturabilirler.

Development Team, kurum tarafından işlerini gerçekleştirmek ve yönetmekle yapılandırılmıştır ve yetkilendirilmiştir. Elde edilen sinerji Development Team’in tüm verimliliğini ve etkinliğini en iyi seviyeye çıkarır.

Development Team, aşağıdaki özelliklere sahiptir:

  • Kendi kendini organize eder. Hiç kimse, Scrum Master bile, Development Team’e gelecek sürümdeki işi nasıl gerçekleştireceğini söyleyemez. Özetle hiç kimse Development Team’e işini nasıl yapacağını söyleyemez.
  • Development Team, çapraz fonksiyoneldir(cross-functional), bir artım oluşturmak için gerekli olan tüm yeteneklere sahiptir.
  • Scrum, Development Team için Developer dışında bir unvan tanımaz. Bu kuralda istisna yoktur.
  • Scrum, Development Team’in altında bir takım oluşturulmasını tanımaz, Testing ya da Business Analysis gibi belirlenen özel bölümleri gözetmeksizin. Bu kuralda istisna yoktur.
  • Development Team’in her bir üyesi özelleştirilmiş yeteneklere ve odak alanlarına sahip olabilir fakat sorumluluk bir bütün olarak Development Team’e aittir.
Development Team’in Büyüklüğü

Development Team, çevik kalacak kadar küçük ve Sprint içindeki işlerin tamamlanmasına yetecek kadar büyüktür.

3 kişiden az üyeli Development Team’lerde etkileşim azalmakta ve sonuç olarak verimlilik azalmaktadır. Üye sayısı az olan Development Team’lerde Sprint süresince yetenek kısıtlarıyla karşılaşılabilir. Bu, Development Team’in yeni bir sürüm(artım) çıkaramamasına neden olabilir.

9 kişiden fazla sayıda üyeye sahip olmak çok koordine olmayı gerektirir. Büyük Development Team’ler, deneysel süreçler için çok fazla karmaşıklık yaratır. Eğer Sprint Backlog’tan iş almıyorlarsa Product Owner ve Scrum Master rolleri bu sayılara dahil değildir.

Scrum Master

Scrum Master, Scrum’ın anlaşılmasından ve yürütülmesinden sorumludur. Scrum Master, Scrum Takımının, Scrum teori, pratik ve kurallarına bağlı kalması işini yapar.

Scrum Master, Scrum Takımı için Hizmetkar Lider – çalışanlarına öncelik veren, onların huzurunu düşünen ve adaletli olan mütevazı lider – dir. Scrum Master, Scrum Takımı dışındakilerin, Scrum Takımı’yla hangi etkileşimlerinin Scrum Takımı’na yardımcı olduğunu ya da olmadığını anlamalarını sağlar. Scrum Master, bu etkileşimlerin değişmesi için herkese yardımda bulunur ve Scrum Takımı tarafından oluşturulan değeri en yüksek seviyeye çeker.

Scrum Master’ın Product Owner’a Hizmeti

Scrum Master, Product Owner’a birkaç şekilde hizmette bulunur:

  • Etkili Product Backlog yönetimi için teknikler bulur.
  • Scrum Takımı’na net ve kısa Product Backlog maddelerini anlamasında yardımcı olur.
  • Product Owner’ın deneysel ortamda ürün planlamasını anlamasına yardımcı olur.
  • Product Owner’ın, değeri en yükseğe çıkarmak için Product Backlog’u nasıl düzenleyeceğini bildiğinden emin olur.
  • Çevikliği(agility) anlar ve uygular.
  • İhtiyaç durumunda Scrum Etkinliklerini gerçekleştirir.
Scrum Master’ın Development Team’e Hizmeti

Scrum Master, Development Team’e birkaç şekilde hizmette bulunur:

  • Development Team’e kendi kendini yönetmesinde ve çapraz fonksiyonel olmasında koçluk eder.
  • Yüksek değerli ürün oluşturmak için yardım eder.
  • Development Team’in ilerleyişinin önündeki engelleri kaldırır.
  • İhtiyaç durumunda Scrum Etkinliklerini gerçekleştirir.
  • Kurumsal ortamlarda tam anlamıyla Scrum’a adapte olamamış ve anlamamış Development Team’e koçluk eder.
Scrum Master’ın Kuruma Hizmeti

Scrum Master, Kuruma birkaç şekilde hizmette bulunur:

  • Scrum adaptasyon sürecinde Kuruma rehberlik ve koçluk eder.
  • Kurum içinde Scrum uygulamalarını planlar.
  • İşveren ve destekçilere Scrum’ı ve deneysel ürün geliştirmeyi anlamalarında ve hareket etmelerinde yardımcı olur.
  • Scrum Takımı’nın verimliliğini arttıran değişiklikler yapar.
  • Kurum içinde Scrum uygulanmasının etkinliğini arttırmak için diğer Scrum Master’lar ile  çalışır.
Scrum Toplantıları

Scrum içinde tanımlanmamış toplantı sayısını en aza çekmek için Scrum içinde belirlenmiş toplantılar bulunur. Bütün toplantılar belirli bir zaman içinde tamamlanması gereken(time-boxed) toplantılardır. Öyle ki her toplantı maksimum süreye sahiptir. Bir Sprint başladığında, bu Sprint’in süresi belirlenmiştir ve kısaltılamaz ya da uzatılamaz. İçinde bulunulan etkinlik amacına ne zaman ulaşırsa bir sonrakine geçilebilir, süreç içinde uygun miktar zaman harcayıp zamanın israf olmasına izin verilmemelidir.

Scrum içindeki her toplantı gözlem ve adaptasyon için bir fırsattır. Bu toplantılar, şeffaflığı ve gözlemi etkinleştirmek için özellikle tasarlanmıştır. Bu toplantıların herhangi birindeki başarısızlık şeffaflıkta düşüşle sonuçlanır. Şeffaflıktaki bu düşüş gözlem ve adaptasyon fırsatının kaybolmasına neden olur.

Time-box nedir?

Agile yazılım geliştirmede, time-box tanımlanmış bir zaman dilimidir. Bu sürede görev başarıyla tamamlanmış olmalıdır. Time-Box’lar genelde yazılım geliştirme risklerini yönetmek için kullanılırlar.

Sprint

Sprint, Scrum’ın kalbidir. Bir ay ya da daha kısa süre ile sınırlanmıştır. DoD’a uyan, kullanılabilir ve potansiyel olarak release edilebilir ürün artımı oluşturulan süredir. Sprint’ler, geliştirme boyunca en iyi sonuç için tutarlı sürelere sahip olmalıdır. Yeni bir Sprint, bir önceki Sprint’in bitişinden hemen sonra başlar.

 

Sprint’ler, Sprint Planning, Daily Scrum’lar, geliştirme işi, Sprint Review ve Sprint Retrospective’i içerir.

 

Sprint süresince:

  • Sprint’in hedefini tehlikeye atan değişiklikler yapılmaz.
  • Kalite hedefleri azaltılamaz.
  • Daha fazla öğrendikçe Product Owner ve Development Team kapsamı açıklığa kavuşturulabilir ve tekrar müzakere edebilir.

Her Sprint, bir aydan fazla sürmeyecek kapsama sahip proje şeklinde düşünülebilir. Projeler gibi, Sprint’ler bir şeyi başarmak için kullanılırlar. Her Sprint, oluşturulan şeyin tanımına, tasarımına ve esnetilebilir plana sahiptir ki bu plan oluşturulmasına, harcanan emeğine ve ürünün sonuçlandırılmasına rehberlik edecektir.

Sprint’ler bir takvim ayıyla sınırlıdırlar. Bir Sprint’in süresi çok uzun olduğunda ne üretildiğinin tanımı değişebilir, karmaşıklığı artabilir ve riski yükselebilir. Sprint’ler, en az her takvim ayında ilerlemenin gözlemlenmesi ve adaptasyonu ile Sprint Hedefi yönünde tahmin edilebilirliği etkinleştirir. Sprint’ler aynı zaman da riski bir takvim ayının maliyeti ile sınırlandırır.

Sprint İptali

Bir Sprint, Sprint’in time-box’ı sona ermeden önce iptal edilebilir. Sadece Product Owner, Sprint’i iptal etme yetkisine sahiptir.

Eğer Sprint Hedefi değerini kaybettiyse Sprint iptal edilebilir. Eğer kurum yön değiştirirse ya da pazar, piyasa veya teknoloji şartları değişirse Sprint iptal edilebilir. Eğer Sprint belirli şartlar altında bir anlam ifade etmiyorsa, bu Sprint iptal edilmelidir. Fakat Sprint’lerin kısa süreleri nedeniyle iptal işlemi çok nadir olarak mantıklıdır.

Bir Sprint iptal edilirken, tamamlanmış ve DONE seviyesindeki Product Backlog maddeleri yeniden gözden geçirilir. Eğer yapılan işin bir bölümü potansiyel olarak yayınlanabilirse Product Owner genellikle bunu kabul eder. Tamamlanmamış Product Backlog maddelerinin tamamı yeniden tahmin edilir ve Product Backlog maddelerine yeniden eklenir. Bunlar üzerinde yapılmış işler hızlıca değer kaybeder ve sıkça yeniden tahmin edilmelidir.

Sprint iptalleri kaynakları tüketir ta ki herkes başka bir Sprint Planning’te tekrar gruplandırılıp başka bir Sprint’e başlayıncaya kadar. Sprint iptalleri, çoğu kez Scrum Takımı üzerinde travma yaratır ve çok nadir meydana gelir.

Sprint Planning

Sprint içinde gerçekleştirilecek iş Sprint Planning’de belirlenir. Bu planlama, tüm Scrum Takımı’nın işbirliğiyle oluşturulur.

 

Sprint Planning, bir aylık Sprint’in planlanması için 8 saat süreyle sınırlıdır. Daha kısa Sprint’ler için bu etkinlik genellikle daha kısadır. Scrum Master toplantının gerçekleştirilmesini ve katılımcıların toplantının amacını anlamasını sağlar. Scrum Master, Scrum Takımı’na toplantıyı time-box içinde tutmayı öğretir.

 

Sprint Planning aşağıdakileri cevaplar:

  • Gelecek Sprint’in sonucunda ne teslim edilebilir?
  • Teslim edilmesi gereken iş nasıl gerçekleştirilecek?
Konu 1: Bu Sprint’te NE yapılacak?

Development Team, Sprint süresince geliştirilecek olan işi büyüklendirmeye çalışır. Product Owner, Sprint’te neyin elde edileceğini ve Product Backlog maddelerini anlatır. Scrum Takımı’nın tamamı Sprint’te gerçekleştirilecek işi anlamak için beraber çalışır.

Bu toplantının girdileri Product Backlog, en son gerçekleştirilen ürün sürümü, Sprint boyunca Development Team’in geliştirme kapasitesi ve Development Team’in geçmiş performansıdır. Sadece Development Team gerçekleştirilmek üzere olan Sprint’te neler yapılacağını belirleyebilir.

Development Team’in Product Backlog maddelerini büyüklendirmesinden sonra oluşturulan Sprint Backlog, Sprint içinde tamamlanacaktır. Scrum Takımı, Sprint Hedefini belirler. Sprint Hedefi, Sprint için seçilen Product Backlog maddelerinden belirlenecektir ve Development Team’e neden bir artım oluşturdukları hakkında rehberlik sağlayacaktır.

Konu 2: Seçilmiş İş NASIL Yapılacak?

Sprint Hedefi ve Sprint için seçilmiş Product Backlog maddeleri belirlendikten sonra Development Team bu işi DONE tanımına uygun bir şekilde bir Sprint süresinde nasıl oluşturabileceğine karar verir. Bu Sprint için seçilmiş Product Backlog maddeleri ve bu maddeleri teslim etmek için yapılan planlamaya Sprint Backlog olarak denir.

İhtiyaç duyulan iş ya da tahmin edilen uğraş değişen boyutlarda olabilir. Development Team’in gelecek Sprint içinde yapabileceğine inandığı, yeterli miktarda iş planlanır. Sprint’in ilk günleri için planlanan iş Development Team’de bu toplantıda paylaştırılır, genelde bir günlük ya da daha az birimlere ayrılarak.

Sprint Planning’te ve Sprint içinde ihtiyaç duyulduğunda Development Team, Sprint Backlog içindeki işi kendi kendine organize olarak üstlenir.

Product Owner seçilmiş Product Backlog maddelerini açıklığa kavuşturmak için yardım edebilir ve bu maddeleri dengeleştirebilir, iyileştirebilir(birinden ödün vererek diğerini iyileştirmek). Eğer Development Team, Sprint Backlog’ta çok fazla ya da çok az iş olduğuna karar verirse, Product Owner ile seçilmiş Product Backlog maddeleri üzerine yeniden müzakere edebilir. Development Team aynı zamanda teknik tavsiye ya da alanlarıyla ilgili diğer kişileri toplantıya katılmaları için davet edebilir.

Sprint Planning’in sonunda, Development Team, Product Owner’a ve Scrum Master’a nasıl kendi kendine organize olarak Sprint Hedefi’ne ulaşacağını ve tahmin edilen Artımı oluşturacağını açıklayabilmelidir.

Sprint Hedefi

Sprint Hedefi, Sprint’in, Sprint Backlog’u karşılayan anahtarıdır. Development Team’e, bu Artımı neden gerçekleştirdikleri üzerine rehberlik sağlar. Sprint Hedefi, Sprint Planning toplantısında oluşturulur. Sprint Hedefi, Development Team’e Sprint içinde eklenen işlevselliğe ilişkin bilgi sağlar. Sprint Hedefi, Development Team’in hep beraber çalışacağı bir konu seçilebilir.

Development Team çalışırken Sprint Hedefi akılda tutulmalıdır. Sprint Hedefine ulaşmak için, Development Team işlevsellik ve teknoloji sağlar. Eğer yapılan iş Development Team’in beklentisinden farklı bir şekilde gerçekleşirse, Sprint bitmeden, Product Owner ile bir araya gelerek Sprint Backlog üzerinden müzakere ederler.

Daily Scrum

Daily Scrum, Development Team için eylemleri senkronize etme ve gelecek 24 saat için bir planlama oluşturmak için ayrılan, 15 dakika süren bir toplantıdır. Bu, son Daily Scrum’dan bu zamana kadar yapılan işlerin gözlemlenmesi ve gelecek Daily Scrum’a kadar neler yapılabileceği üzerine tahminlerde bulunarak son bulur. Daily Scrum, karmaşıklığı azaltmak için her gün, aynı zaman ve yerde düzenlenir. Toplantı süresince Development Team üyeleri aşağıdakileri açıklar:

Development Team, Daily Scrum’ı Sprint Hedefi yönünde ilerlemeyi gözlemlemek ve Sprint Backlog’taki işin hangi yönde tamamlandığını denetlemek için kullanırlar. Daily Scrum, Development Team’in Sprint Hedefine ulaşma olasılığını en iyi seviyeye çeker. Her gün, Development Team Sprint Hedefine başarıyla ulaşabilmek için nasıl kendi kendine organize bir takım olarak beraber çalışabileceğini anlamalı ve Sprint sonunda beklenen Artımı oluşturmalıdır. Development Team, Daily Scrum’dan sonra Sprint’in kalan işiyle ilgili detaylandırılmış bir tartışma ve yeniden planlama ile sıkça karşılaşır.

Scrum Master, Development Team’in toplantı yapmasını sağlar fakat Daily Scrum’ın yapılmasından Development Team sorumludur.

Scrum Master, Development Team’e Daily Scrum’ı 15 dakikalık zamanda tutmayı öğretir.

Scrum Master, Daily Scrum’a sadece Development Team üyelerinin katılabileceği kuralını uygulatır.

Daily Scrum’lar iletişimi geliştirir, diğer toplantıları azaltır, kaldırılması için engelleri tanımlar, çabuk karar vermeyi vurgular ve destekler ve Development Team’in bilgi seviyesini yükseltir. Daily Scrum, gözlem ve adaptasyonun anahtarıdır.

Sprint Review

Sprint Review, Sprint sonunda yapılan işi gözlemlemek ve Product Backlog’u adapte etmek için düzenlenir. Sprint Review toplantısında, Scrum Takımı ve Proje Destekçileri NE yapıldığına dair görüşmek için Sprint sonunda bir araya gelir. Sprint süresince değeri en iyi seviyeye çekmek için yapılmış olan çalışmaları görüşmek için katılımcılar bir araya gelir ve bu toplantının temelidir. Bu resmi olmayan bir toplantıdır, durum toplantısı değildir, geri dönüşler almak ve işbirliğine teşvik etmek niyetiyle Artımın sunumu yapılır.

Sprint Review toplantısı bir aylık Sprint için 4 saatle sınırlandırılmış bir toplantıdır. Daha kısa Sprint’ler için toplantı genelde daha kısadır. Scrum Master, toplantının düzenlenmesini ve katılımcıların bu toplantının amacını anlamasını sağlar. Scrum Master, herkese toplantıyı belirlenen süre limitinde tutmayı öğretir.

Sprint Review toplantısı aşağıdakileri içerir:

  • Scrum Takım üyeleri ve anahtar Proje Destekçileri, Product Owner tarafından davet edilir.
  • Product Owner, Product Backlog maddelerinden hangilerinin DONE tanımına uyduğunu, hangilerinin uymadığını açıklar.
  • Development Team, Sprint süresince nelerin iyi gittiğini, nelerin iyi gitmediğini ve yaşanan problemlerin nasıl çözüleceğini anlatır.
  • Development Team, DONE tanımına sahip Product Backlog maddelerinin sunumunu yapar ve bu maddeler hakkındaki soruları cevaplandırır.
  • Product Owner, gerçekleştirilen ilerlemeyi temel alarak projenin olası tamamlanma tarihini belirler.
  • Toplantı grubunun tamamı sıradaki adımın ne olduğuna dair görüşlerini bildirir böylece Sprint Review toplantısı, sonraki Sprint Planning toplantısı için değerli bir girdi sağlar.
  • Pazarın, piyasanın veya ürünün kullanımının nasıl değişebileceği ve sıradaki adımda yapılabilecek en değerli şeyin ne olacağına dair kısa bir gözden geçirme yapılır.
  • Ürünün gelecek tahmini sürümü için zaman, bütçe, yetkinlikler ve pazar, piyasa yeniden gözden geçirilir.

Sprint Review sonucunda, Product Backlog yeniden incelenir ve büyük ihtimalle gelecek Sprint’in Sprint Backlog maddeleri kısaca anlatılır. Bu toplantıda gelen görüşler üzerine Product Backlog yeniden düzenlenebilir.

Sprint Retrospective

Sprint Retrospective, Scrum Takımı’nın kendini gözlemlemesi ve gelecek Sprint’te kullanılmak üzere iyileştirmeler planlaması için bir fırsattır.

 

Sprint Retrospective, Sprint Review’den sonra ve sıradaki Sprint Planning’ten önce yapılır. Bir aylık Sprint için 3 saatle sınırlı bir toplantıdır. Genellikle daha kısa Sprint’ler için bu toplantı daha kısadır. Scrum Master, toplantının düzenlenmesini ve katılımcıların bu toplantının amacını anlamasını sağlar. Scrum Master, herkese toplantıyı belirlenen süre limitinde tutmayı öğretir. Scrum Master, Scrum sürecinin güvenilirliği için bir takım üyesi olarak toplantıya katılır.

Sprint Retrospective’in amacı:

  • Son Sprint’in ilgili kişiler, ilişkiler, süreç ve araçlar için nasıl geçtiğinin değerlendirilmesi.
  • İyi geçen başlıca maddelerin ve iyileştirmelerin belirlenmesi ve sıralanması.
  • Scrum Takımı’nın işini yapış şeklindeki iyileştirmelerin yapılabilmesi için planlama oluşturulması.

Scrum Master, Scrum Takımını ilerleme için teşvik eder. Geliştirme sürecinin ve etkinliklerin daha verimli ve eğlenceli hale getirilmesi için çaba sarfeder.

Her Sprint Retrospective’de, Scrum Takımı DONE tanımına uygun ürün kalitesini artırmak için yollar arar.

Sprint Retrospective sonunda, Scrum Takımı gelecek Sprint’te uygulanmaya başlanacak iyileştirmelere sahip olmalıdır. Sıradaki Sprint’te bu iyileştirmelerin eklenmesi Scrum Takımı’nın kendini gözlemlemesinin adaptasyonudur. Ayrıca iyileştirmeler herhangi bir zamanda gerçekleştirilebilir. Sprint Retrospective gözleme ve adaptasyona resmi bir fırsat sağlar.

Scrum Artifact’leri

Scrum Artifact’leri, şeffaflık, gözlem ve adaptasyona fırsatlar sağlar. Scrum tarafından tanımlanan Artifact’ler özellikle anahtar bilgilerin şeffaflığını en yüksek seviyeye çekmek için tasarlanmıştır, öyle ki herkes artifact’ten aynı anlamı çıkarmalıdır.

Product Backlog

Product Backlog, ürün için gerekli olabilecek her şeyin sıralı bir listesidir ve üründe yapılan bütün değişiklilerin tek kaynağıdır. Product Owner, Product Backlog’dan, içeriğinden, erişilebilirliğinden ve sıralanmasından sorumludur.

Bir Product Backlog asla tamamlanmaz. Product Backlog’un erken safhalarında sadece başlıca bilinen ve en iyi anlaşılmış gereksinimleri ortaya koymaktadır. Product Backlog, ürün ve içinde bulunduğu ortamla gelişir. Product Backlog dinamiktir, sürekli olarak ürünün uygun muadilleriyle yarışabilir kalması için güncellenir. Ürün var olduğu sürece Product Backlog var olur.

Product Backlog bütün özellikleri, işlevleri, ihtiyaçları, geliştirmeleri ve düzeltmeleri listeler, üründe yapılan değişiklikleri içerir. Product Backlog maddeleri tanım, sıralama, tahmin ve değer özelliklerine sahiptir.

Ürünün kullanılması, değer kazanması ve pazarın sağladığı geri dönüşler, Product Backlog’u daha büyük ve ayrıntılı bir listeye dönüştürür. Gereksinimler sürekli değişir, bu Product Backlog’u yaşayan bir öğe yapar. İşin yapılış şeklindeki değişiklikler, pazar koşulları ya da teknoloji Product Backlog’ta değişikliklere neden olabilir.

Birçok Scrum Takımı aynı ürün üzerinde beraber çalışıyor olabilir, bir Product Backlog, ürünle ilgili sıradaki işi ifade etmek için kullanılabilir. Bu durumda Product Backlog maddelerine bu maddenin hangi takım tarafından üstlenildiği bilgisi eklenmelidir.

Product Backlog maddelerinin detaylandırılması işi şunları içerir; detayların eklenme eylemi, tahminler ve Product Backlog’taki maddelerin sıralanması. Product Backlog maddelerinin detaylandırılması, Product Owner ve Development Team’in iş birliği yaptığı, sürekliliği olan bir operasyondur. Product Backlog gelişimi süresince maddeler yeniden gözden geçirilir ve incelenir. Scrum Takımı detaylandırma işinin nasıl ve ne zaman biteceğine karar verir. Detaylandırma işi bir Sprint’in % 10’undan fazlasını aşmamalıdır. Product Backlog maddeleri, Product Owner tarafından ya da Product Owner direktifiyle her zaman güncellenebilir.

Product Backlog’ta yukarıda bulunan maddeler, altta bulunan maddelere göre genelde daha net ve daha detaylıdır. Kesine yakın tahminlerin temeli daha net ve fazla detaya dayanır; altta bulunan maddelerin önceliği düşüktür dolayısıyla daha az detaya sahiplerdir. Product Backlog maddeleri, Sprint Planning’te READY olarak kabul edilen ve bir Sprint içinde Development Team tarafından DONE tanımına uygun hale getirilebilecek maddelerdir. Product Backlog maddeleri genelde bu derece şeffaflığı yukarıda ifade edilen detaylandırma eyleminden sonra kazanırlar.

Development Team bütün tahminlerden sorumludur. Product Owner, Development Team’e tahminleri yapmada ve dengeleri belirlemede yardım ederek etki edebilir. Fakat işi yapacak kişiler son tahmini yapar.

Hedefe Doğru İlerlemenin Gözlemlenmesi

Zaman içinde herhangi bir noktada amaca ulaşmak için yapılması gereken toplam iş belirlenebilir. Product Owner, en azından her Sprint Review Toplantısı’nda kalan işi belirler. Product Owner, kalan iş miktarını, hedef için belirlenen zamanda tamamlanması yönündeki ilerlemeyi belirlemek için önceki Sprint Review Toplantılarındaki iş miktarlarıyla karşılaştırır. Bu bilgi bütün Proje Destekçilerine şeffaf bir şekilde belirtilir.

Çeşitli grafikler ilerlemeyi tahmin etmek için kullanılabilir, örneğin Burn-Up, Burn-Down grafikler ya da Cumulative Flow Diagram’lar. Bunların kullanışlı olduğu kanıtlanmıştır. Yine de bunlar deneyciliğin önemiyle karşılaştırılamaz. Karmaşık ortamlarda ne olabileceği bir bilinmezdir. Sadece neler olduğu ileriye dönük kararlar almada kullanılabilir.

Sprint Backlog

Sprint Backlog, Sprint için seçilmiş Product Backlog maddelerinden oluşan bir kümedir, artı ürün artımının ulaştırılması için bir planlama ve Sprint Hedefi’nin belirlenmesidir. Sprint Backlog, sıradaki Artımda hangi özelliklerin ekleneceği ve bu özellikleri DONE tanımına ulaştıracak ihtiyaç duyulan iş hakkında Development Team tarafından yapılan bir tahmindir.

Sprint Backlog, Development Team’in Sprint Hedefine ulaşılması için gerekli olarak belirlediği işin tamamını görünür kılar. Sprint Backlog, ilerlemeyle değişen, yeterince detaylandırılmış bir plandır ve Daily Scrum’larda güncellenir.

Development Team, Sprint sırasında – Sprint sürerken – Sprint Backlog’u değiştirir. Development Team planlama doğrultusunda çalışırken ve Sprint Hedefine ulaşmak için gerekli iş hakkında daha fazla bilgi sahibi olurken, bu değişimi gerçekleştirir.

Yeni bir işe ihtiyaç duyulduğunda, Development Team, Sprint Backlog’a bunu ekler. İş gerçekleştirildiğinde ya da tamamlandığında, tahmin edilen yapılması gereken iş – kalan iş – güncellenir. Planlamanın içeriğinde gereksiz içerik bulunuyorsa bunlar kaldırılır, silinir. Sprint devam ederken sadece Development Team Sprint Backlog’u değiştirebilir.

Sprint Backlog son derece şeffaf, Development Team’in Sprint süresinde başarılı olmak için planladığı, işin gerçek zamanlı bir resmidir ve sadece Development Team’e aittir.

Sprint İlerlemesinin Gözlenmesi

Sprint içindeki herhangi bir noktada, Sprint Backlog içinde yapılması gereken toplam iş belirlenebilir. Development Team, kalan bu toplam işi en azından her Daily Scrum için belirleyebilir. Böylece Sprint Hedefine ulaşma olasılığını projelendirir. Sprint boyunca kalan işin takibiyle Development Team ilerleyişini yönetebilir.

Artım(Increment)

Artım, bir Sprint süresinde tamamlanan Product Backlog maddelerinin toplamıdır. Bunun anlamı; bu Artım kullanılabilir durumdadır ve Scrum Takımı’nın DONE tanımına uymaktadır. Product Owner’ın ürün sürümünü gerçekleştirmesi yada gerçekleştirmemesi kararına bakılmaz, ürün kullanılabilir olmalıdır.

Artifact Şeffaflığı

Scrum, şeffaflığa dayanır. Değeri en iyi seviyeye çekmek ve riski kontrol etmek için alınan kararlar, artifact’ların durumuna dayanır. Bu derece şeffaflığı sağlamak için kararlar sağlam bir temele sahip olmalıdır. Artifact’lerin bu derece şeffaflığı sağlanmamışsa kararlar kusurlu olabilir, değer azalabilir ve risk yükselebilir.

Eğer Artifact’ler tamamıyla şeffaf değilse, Scrum Master, Product Owner, Development Team ve dâhil olan diğer kişilerin anlaması için onlarla beraber çalışmalıdır. Tamamıyla oluşturulamamış şeffaflıkla başa çıkmak için teknikler bulunmalıdır.

 

Scrum Master, şeffaflığı sağlayamayan herkese yardım etmelidir. Bir Scrum Master artifact’leri denetleyerek, örnekleri anlayarak, ne söylendiğini yakından dinleyerek ve beklenen ile gerçekleşen sonuçlar arasındaki farkları tespit ederek eksik şeffaflığı belirleyebilir.

Scrum Master’ın görevi, Scrum Takımı ve kurum ile çalışarak artifact’leirn şeffaflığını arttırmaktır. Bu göreve genellikle öğrenmek, ikna etmek ve değişiklik yapmak dâhildir. Şeffaflık bir gecede meydana gelmez, bu uzun bir yoldur.

DONE Kriterinin Tanımı

Bir Product Backlog maddesi ya da bir Artım DONE olarak tanımlandığında, herkes DONE’ın ne anlama geldiğini bilmelidir. Bu her Scrum Takımı’nda çok farklılık göstermekle birlikte, üyeler işin tamamlandığına dair ortak anlayışa sahip olmalıdırlar. Bu Scrum Takımı için DONE kriterinin tanımıdır ve iş tamamlandığında kullanılır.

Aynı tanım,  Development Team’e bir Sprint Planning süresince kaç Product Backlog maddesi seçebileceği konusunda rehberlik eder. Her Sprint’in amacı, Scrum Takımı’nın geçerli DONE kriterine bağlı, potansiyel sürümlenebilir işin Artımlarını ulaştırmaktır.

Development Team’ler, her Sprint’te ürün Artımını oluştururlar. Artım kullanışlıdır bu nedenle Product Owner çabucak yayınlanmasını seçebilir. Eğer bir Artım için DONE kriterinin tanımı geliştirme organizasyonunun uzlaştığı bir konunun, standartlarının ya da kurallarının parçasıysa, bütün Scrum Takımları takip etmelidir. Eğer bir Artım için DONE kriteri geliştirme organizasyonunun uzlaştığı bir konu değilse, Scrum Takımı’nın içindeki Development Team ürün için uygun DONE kriterinin tanımını yapmalıdır. Eğer sistem ya da ürün üzerinde birden fazla Scrum Takımı çalışıyorsa bütün Scrum Takımları’nın Development Team’leri karşılıklı olarak DONE kriterinin tanımını yapmalıdırlar.

Her Artım önceki tüm Artımlara katkıdır ve iyice test edilmiş olmalıdır, bütün Artımların beraber çalıştığı garanti edilmelidir.

Scrum Takımları olgunlaştıkça, daha yüksek kalite için Scrum Takımı’nın DONE kriteri tanımlarının daha sıkı kriterleri içine alacak şekilde genişletilmesi beklenir. Herhangi bir ürün ya da sistem üzerinde yapılan her iş için bir DONE kriterine sahip olunmalıdır.

Bitiş Notu

Bu rehber ücretsizdir ve önerilir. Scrum rolleri, artifact’leri, etkinlikleri ve kuralları değişmezdir. Scrum parçalarının uygulanması mümkündür, bunun sonucu Scrum değildir. Scrum sadece onun bütünlüğü içinde var olur. Scrum’ın bütünlüğü korunarak diğer teknikler, metodolojiler ve pratikleri kullanılabilir.

 

 

259total visits,1visits today

2 thoughts on “Scrum Klavuzu

  1. Pingback: Daily Scrum

Leave a Reply

Your email address will not be published. Required fields are marked *