Scrum Kılavuzu’nu bağlantıdan indirebilirsiniz:

Scrum Kılavuzu

1 file(s) 634.94 KB

Download

Scrum Kılavuzu’nun Amacı

Scrum, karmaşık ürünlerin geliştirilmesi, teslim edilmesi ve bu ürünlerin bakım çalışmaları için bir çerçevedir. Bu kılavuz Scrum’ın tanımını içerir. Bu tanım içinde Scrum’da bulunan roller, etkinlikler, araçlar ve bunların hepsini bir araya getiren kurallar bulunmaktadır. Scrum’ı, Ken Schwaber ve Jeff Sutherland geliştirmiştir. Scrum Kılavuzu, onlar tarafından yazılmıştır ve sunulmuştur. Scrum Kılavuzu’nun arkasında beraber dururlar.

Scrum’ın Tanımı

Scrum(isim): Olası en yüksek değere sahip ürünlerin üretken ve yaratıcı bir şekilde teslimi yapılırken insanların karmaşık adaptif problemleri çözebildiği bir çerçevedir.

Scrum:

• Sadedir
• Anlaması basittir
• Hakim olması(yönetmesi) zordur

Scrum, 1990’ların başından beri karmaşık ürünlerin yönetiminde kullanılan bir süreç çerçevesidir. Scrum süreç, teknik ya da önceden tanımlanmış bir yöntem değildir. Bundan öte içinde çeşitli süreçleri ve teknikleri kullanabileceğiniz bir çerçevedir. Scrum, ürün yönetimi ve çalışma tekniklerinizin göreceli etkisini netleştirir böylece ürün, takım ve çalışma ortamı sürekli olarak geliştirilebilir.

Scrum çerçevesinin içinde Scrum Takımı, ilişkili rolleri, etkinlikleri, araçları ve kuralları bulunur. Çerçeve içindeki her bir öğe belirli bir amaca hizmet eder ve Scrum’ın başarısı ve kullanımı için hayati öneme sahiptir.

Scrum’ın kuralları, rolleri, etkinlikleri ve araçları bir araya getirir ve bunlar arasındaki ilişkileri ve etkileşimi yönetir. Scrum’ın kuralları bu dokümanda anlatılır.

Scrum kullanımı için belirli taktikler farklılık gösterir ve bir başka yerde tanımlanmıştır.

Scrum’ın Kullanılışı

Scrum ilk önceleri ürünlerin yönetimi ve geliştirilmesi için geliştirilmişti. Scrum, 1990’ların başından itibaren dünya çapında yaygın olarak aşağıdaki konularda kullanılmaya başlandı:

1. Değerli pazarları, teknolojileri ve ürün yeteneklerini araştırma ve tanımlama
2. Ürün ve ürünle ilgili iyileştirmeleri geliştirme
3. Ürün ve ürünle ilgili iyileştirmelerin gün içinde birçok defa yaygınlaştırılması
4. Bulut(çevrimiçi, güvenli, isteğe bağlı) ve diğer operasyonel ortamların ürün kullanımı için geliştirilmesi ve sürdürülür kılınması
5. Ürünlerin sürdürülür olması ve yenilenmesi

Scrum, yazılım, donanım, gömülü yazılım, etkileşimli işlem ağları, otonom araçların geliştirilmesi, okullar, devlet, pazarlama, organizasyonel işlerin yönetimi ve neredeyse günlük hayatın her alanında bireyler ve toplumlar tarafından kullanıldı.

Teknoloji, pazar ve çevresel karmaşıklıklar ve bunların birbiriyle etkileşimleri çok hızlı bir şekilde arttı. Scrum’ın karmaşıklıkla başa çıkmadaki faydası her gün kanıtlanır oldu.

Scrum’ın özellikle döngüsel ve artımlı bilgi aktarımında etkili olduğu kanıtlandı. Şimdi Scrum, ürün, hizmet ve büyük organizasyonların yönetiminde yaygın bir şekilde kullanılıyor.

Scrum’ın özü, az sayıda kişiden oluşan bir takımdır. Küçük bir takım oldukça esnek ve adaptiftir. Bu güçlü yönler, işin ve binlerce kişinin ürettiği ürünlerin geliştirilmesinde, yaygınlaştırılmasında, çalışmasında ve sürdürülebilir olmasında bir takım, birkaç takım, birçok takım ve takımlardan oluşan büyük bir ağda çalışmaya devam eder. Bu takımlar, çok yönlü(gelişmiş) geliştirme mimarileri ve hedef yaygınlaştırma ortamları aracılığıyla iş birliği yaparlar ve beraber çalışırlar. Bu takımlar, sofistike geliştirme mimarileri ve hedef teslim ortamları aracılığıyla iş birliği içinde çalışırlar.

Scrum Kılavuzu’nda, “gelişim” ve “geliştirme” sözcükleri yukarıda olduğu gibi karmaşık işleri anlatmak için kullanılır.

Scrum Teorisi

Scrum, deneysel süreç kontrol teorisi ya da deneycilik üzerine kurulmuştur. Deneycilik, bilginin tecrübeden geldiğini ve karar alma işinin ne bildiğimize dayalı olduğunu savunur. Scrum, tahmin edilebilirliği ve riski optimize etmek için döngüsel ve artımlı bir yaklaşım benimser.

Deneysel süreç kontrolünün uygulanışını üç sütun destekler: şeffaflık, gözlem ve adaptasyon.

Şeffaflık

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

• Sürece dair ortak bir dil tüm katılımcılarla paylaşılmalıdır.
• İşi yapanlar ve iş sonucu oluşan ürünü gözlemleyenler ortak bir “Bitti” tanımını paylaşmalıdır.

Gözlem

Scrum kullanıcıları, istenmeyen sonuçları belirlemek için Scrum araçlarını ve Sprint Hedefi’ne doğru ilerlemeyi sık sık gözlemlemelidir. Bu gözlemler işin önüne geçecek kadar sık olmamalıdır. Gözlemler, yetkin gözlemciler tarafından özenle yerine getirilirse en çok yararı sağlar.

Adaptasyon

Eğer gözlemci sürecin bir ya da daha fazla açıdan kabul edilebilir limitlerin dışına çıktığına ve bunun sonucunda üretilen ürünün kabul edilemez olduğuna karar verirse süreç ya da üründe değişikliğe gidilmelidir. Bu değişiklik mümkün olduğunca çabuk yapılmalıdır ki süreçteki ya da üründeki sapma ilerlemeyip, en aza indirgensin.

Scrum,  bu dokümanın Scrum Etkinlikleri bölümünde anlatıldığı gibi, gözlem ve adaptasyon için 4 resmi etkinlik tanımlar.

• Sprint Planlama
• Günlük Scrum
• Sprint Değerlendirme
• Sprint Retrospektif

Scrum Değerleri

Taahhüt, cesaret, odak, açıklık ve saygı değerleri Scrum Takımı tarafından somutlaştırıldığında ve yaşandığında Scrum’ın sütunları şeffaflık, gözlem ve adaptasyon hayat bulur ve herkes için güven inşa eder. Scrum Takımı üyeleri, bu değerleri Scrum rolleri, etkinlikleri ve araçlarıyla çalıştıkça öğrenir ve keşfeder.

Scrum’ın başarılı kullanımı insanların bu beş değeri yaşayarak yetkinliklerini artırmasına bağlıdır. İnsanlar, Scrum Takımı’nın hedeflerine ulaşması için kişisel olarak taahhüt verirler. Scrum Takımı üyelerinin doğru şeyi yapmak ve sorunlar üzerine çalışmak için cesareti vardır. Herkes Sprint’te bulunan işe ve Scrum Takımı’nın hedeflerine odaklanır. Scrum Takımı ve paydaşları bütün işler ve işi yerine getirirken karşılaşılacak zorluklar hakkında açık olma konusunda anlaşırlar. Scrum Takımı’nın her bir üyesi birbirlerinin yeteneklerine ve bağımsızlıklarına saygı duyarlar.

Scrum Takımı

Scrum Takımı, Ürün Sahibi, Geliştirme Takımı ve Scrum Master’dan oluşur. Scrum Takımları kendi kendini yönetir ve çapraz fonksiyoneldir. Kendi kendini yöneten takımlar, takım dışındaki kişiler tarafından yönlendirilmektense işlerini en başarılı şekilde nasıl yapacaklarını kendileri seçerler. Çapraz fonksiyonel takımlar, takımın parçası olmayanlara bağımlı olmadan işlerinde başarılı olmak için ihtiyaç duyulan tüm yetkinliklere sahiptirler. Scrum’daki takım modeli, esnekliği, yaratıcılığı ve üretkenliği optimize edecek şekilde tasarlanmıştır. Scrum Takımı belirtilen ilk kullanımlarında ve karmaşık her işte giderek etkin olduğunu ispat etmiştir.

Scrum Takımları, döngüsel ve artımlı bir yolla, geri bildirim fırsatı olasılığını en yüksek seviyeye çıkararak ürünlerini teslim eder. “Bitti” olan ürünün artımlı olarak teslim edilmesi, çalışan ürünün kullanılabilir bir sürümünün her zaman erişilebilir olmasını sağlar.

Ürün Sahibi

Ürün Sahibi, Geliştirme Takımı’nın çalışmaları sonucu elde edilen ürünün değerini en yüksek seviyeye çıkarmakla sorumludur. Bunun nasıl yapılacağı organizasyonlar, Scrum Takımları ve bireyler arasında farklılık gösterir.

Ürün Sahibi, Ürün İş Listesi’nin yönetiminden sorumlu tek kişidir. Ürün İş Listesi yönetimi aşağıdakileri içerir:

• Ürün İş Listesi’ndeki maddelerin net bir şekilde ifade edilmesi
• Ürün İş Listesi’ndeki maddelerin hedefler ve görevler açısından en iyi şekilde sıralanması
• Geliştirme Takımı’nın yaptığı işin değerinin optimize edilmesi
• Ürün İş Listesi’nin görünür, şeffaf, herkes tarafından anlaşılır ve Scrum Takımı’nın gelecekte neler üzerinde çalışacağını gösterdiğinden emin olma
• Geliştirme Takımı’nın Ürün İş Listesi’nde bulunan iş maddelerini yeterli seviyede anladığından emin olma

Ürün Sahibi yukarıdaki işleri yapabilir ya da Geliştirme Takımı’nın yapmasını sağlayabilir. Her durumda sorumlu Ürün Sahibi’dir.

Ürün Sahibi, bir kişidir, bir komite olamaz. Ürün Sahibi, bir komitenin isteklerini Ürün İş Listesi’ne yansıtabilir fakat Ürün İş Listesi’ndeki iş maddelerinin önceliğini değiştirmek isteyenler Ürün Sahibi’yle görüşmelidir.

Ürün Sahibi’nin başarılı olması için tüm organizasyon Ürün Sahibi’nin kararlarına saygı duymalıdır. Ürün Sahibi’nin kararları, Ürün İş Listesi’nin içeriğinde ve sıralanışında görülebilirdir. Hiç kimse Geliştirme Takımı’nı farklı ihtiyaç listesi için çalışmaya zorlayamaz.

Geliştirme Takımı

Geliştirme Takımı, her Sprint sonunda “Bitti” tanımına uyan, ürünün çalışır parçasını teslim eden profesyonellerden oluşur. “Bitti” tanımına uyan ürün parçası Sprint Değerlendirme etkinliği için bir gerekliliktir. Sadece Geliştirme Takımı üyeleri çalışan ürün parçacığını geliştirir.

Geliştirme Takımları, kendi işlerini organize etmek ve yönetmek için kurum tarafından oluşturulmuş ve yetkilendirilmiştir. Görev paylaşımı Geliştirme Takımı’nın tüm verimliliğini ve etkinliğini en ideal hale getirir.

Geliştirme Takımları aşağıdaki özelliklere sahiptir:

• Kendi kendilerini yönetirler. Hiç kimse(Scrum Master dahil) Geliştirme Takımı’na Ürün İş Listesi’ndeki maddeleri çalışan bir ürüne nasıl dönüştüreceğini söyleyemez.
• Geliştirme Takımları çapraz fonksiyoneldir -çalışan ürün parçacığını geliştirebilmek için gerekli yetkinliklere sahiptir-.
• Scrum, Geliştirme Takımı üyeleri için hiçbir unvanı tanımaz, kişinin yaptığı işe bakılmaksızın.
• Scrum, Geliştirme Takımı içinde alt takımları tanımaz, test, mimari, operasyon, iş analizi gibi alanlara bakılmaksızın.
• Geliştirme Takımı üyelerinin uzmanlaştıkları yetkinlikleri ve odak alanları olabilir fakat sorumluluk bir bütün olarak Geliştirme Takımı’na aittir.

Geliştirme Takımı’nın Büyüklüğü

İdeal Geliştirme Takımı çevik olacak kadar küçük Sprint’e alınacak işlerin çoğunluğunu tamamlayacak kadar büyük olmalıdır. Geliştirme Takımı üye sayısı üçten az olursa etkileşim düşer ve bunun sonucunda üretkenlikte küçük kazançlar elde edilebilir. Küçük Geliştirme Takımları, Sprint süresince yetkinlik kısıtlarıyla karşılaşabilir. Bunun sonucunda Geliştirme Takımı çalışan ürün parçacığını teslim edemeyebilir. Dokuzdan fazla üye olmasıysa çok fazla koordine olmayı gerektirir. Büyük Geliştirme Takımları, çok fazla karmaşıklık üretirler, bu durum deneysel sürecin kullanışlı olmasını engeller. Eğer Sprint İş Listesi’ndeki işleri yapmıyorlarsa Ürün Sahibi ve Scrum Master rolleri bu sayıya dahil değildir.

Scrum Master

Scrum Master, Scrum’ın, Scrum Kılavuzu’nda anlatıldığı şekliyle teşvik edilmesinden ve desteklenmesinden sorumludur. Scrum Master bunu, herkesin Scrum teori, pratikleri, kuralları ve değerlerini anlamasına yardım ederek yapar.

Scrum Master, Scrum Takımı’nın hizmetkar lideridir. Scrum Master, Scrum Takımı dışındaki kişilerin Scrum Takımı’yla olan etkileşimlerinden hangisinin yararlı hangisinin yararlı olmadığını anlamalarına yardım eder. Scrum Master, Scrum Takımı’nın ürettiği değeri en yükseğe çıkarmak için bu etkileşimlerin herkes tarafından değiştirilmesine yardım eder.

Scrum Master’ın Ürün Sahibi’ne Hizmeti

Scrum Master, Ürün Sahibi’ne aşağıdakiler dahil farklı yollarla hizmet eder:

• Hedeflerin, kapsamın ve ürün alanının Scrum Takımı’ndaki herkes tarafından anlaşıldığından emin olunması
• Etkili Ürün İş Listesi yönetimi için teknikler bulunması
• Scrum Takımı’nın açık ve öz Ürün İş Listesi maddelerine olan ihtiyacı anlamasına yardım etme
• Deneysel ortamda ürün planlamasının anlaşılması
• Ürün Sahibi’nin değeri en yükseğe çıkarmak için Ürün İş Listesi’ni nasıl düzenleyeceğini bildiğinden emin olma
• Çevikliği anlama ve uygulama
• Talep edildiğinde ve ihtiyaç olduğunda Scrum etkinliklerini düzenleme

Scrum Master’ın Geliştirme Takımı’na Hizmeti

Scrum Master, Geliştirme Takımı’na aşağıdakiler dahil farklı yollarla hizmet eder:

• Geliştirme Takımı’na kendi kendini yönetmesi ve çapraz fonksiyonel olması konusunda koçluk yapma
• Geliştirme Takımı’na yüksek değerli ürün geliştirmesi için yardım etme
• Geliştirme Takımı’nın ilerlemesinin önündeki engelleri kaldırma
• Talep edildiğinde ve ihtiyaç olduğunda Scrum etkinliklerini düzenleme
• Scrum’ın tam olarak benimsenmediği ve anlaşılmadığı organizasyonlarda Geliştirme Takımı’na koçluk yapma

Scrum Master’ın Organizasyona Hizmeti

Scrum Master, organizasyona aşağıdakiler dahil farklı yollarla hizmet eder:

• Scrum’ın benimsenme sürecinde organizasyona liderlik ve koçluk yapma
• Organizasyon içindeki Scrum uygulamalarını planlama
• Çalışanların ve paydaşların Scrum’ı ve deneysel ürün geliştirmeyi anlamalarına ve buna uygun şekilde davranmalarına yardım etme
• Scrum Takımı’nın üretkenliğini artıracak değişikliklerin yapılmasını sağlama
• Organizasyon içinde Scrum’ın etkisini artırmak için diğer Scrum Master’larla çalışma

Scrum Etkinlikleri

Scrum’da tanımlı etkinlikler, düzen oluşturma ve Scrum’da tanımlı olmayan toplantı ihtiyacını en aza indirmek için kullanılır. Tüm etkinliklerin süresi belirlidir öyle ki her etkinlik maksimum süreye sahiptir. Sprint başladığında, süresi sabittir ve uzatılamaz ya da kısaltılamaz. Diğer etkinliklere süreç içinde çöp yaratmayacak seviyede uygun miktarda zaman harcanır ve etkinlik amacına ulaştığında bitebilir.

Sprint’in kendisi ve içerdiği diğer etkinlikler, gözlem ve adaptasyon için resmi bir fırsattır. Bu etkinlikler, şeffaflık ve gözlemi etkin kılmak için özellikle tasarlanmıştır. Bu etkinliklerin herhangi birini gerçekleştirmede başarısız olmak şeffaflığın azalmasıyla sonuçlanır, gözlem ve adaptasyon için kaçırılmış bir fırsattır.

Sprint

Süresi bir ay ya da daha az olan, bu süre içerisinde “Bitti”, kullanılabilir ve teslim edilebilir bir Ürün Parçası geliştirilen Sprint, Scrum’ın kalbidir. Sprint’in süresi geliştirme süresi boyunca sabittir. Yeni Sprint, bir öncekinin bitişiyle başlar.

Sprint, Sprint Planlama, Günlük Scrum’lar, geliştirme işi, Sprint Değerlendirme ve Sprint Retrospektif etkinliklerini içerir.

Sprint süresince:

• Sprint Hedefi’ni tehlikeye sokacak değişiklikler yapılmaz.
• Kalite hedefleri düşmez.
• Kapsam netleştirilebilir ve daha fazla bilgi sahibi oldukça Ürün Sahibi ve Geliştirme Takımı arasında yeniden görüşülebilir.

Her Sprint, süresi bir ay olan bir proje olarak düşünülebilir. Tıpkı projeler gibi Sprint’te bir şeyleri başarmak için kullanılır. Her Sprint’in, ne geliştirileceğine dair bir hedefi, geliştirmeye rehberlik edecek bir tasarımı ve esnek bir planı, işin kendisi ve bunların sonucu olarak ortaya çıkan ürün parçası vardır.

Sprint’ler bir takvim ayıyla sınırlıdır. Sprint süresi çok uzun olduğunda geliştirilecek şey değişebilir, karmaşıklık artabilir ve risk yükselebilir. Sprint’ler, en az her takvim ayında bir Sprint Hedefi’ne doğru ilerlemenin gözlem ve adaptasyonuyla tahmin edilebilirliği mümkün kılar. Ayrıca Sprint’ler riski bir takvim ayının maliyetiyle sınırlar.

Sprint’i İptal Etme

Sprint, süresi tamamlanmadan iptal edilebilir. Sadece Ürün Sahibi, Sprint’i iptal etme yetkisine sahiptir. Ancak Ürün Sahibi, paydaşların, Geliştirme Takımı’nın ya da Scrum Master’ın etkisi altında kalarak bunu yapabilir.

Sprint Hedefi anlamını yitirirse Sprint iptal edilebilir. Kurum yön değiştirirse ya da pazar veya teknoloji şartları değişirse bu meydana gelebilir. Genel olarak içinde bulunulan şartlarda Sprint’i gerçekleştirmenin anlamı kalmadıysa Sprint iptal edilmelidir. Fakat Sprint’lerin kısa süreleri nedeniyle iptal kararı nadiren mantıklıdır.

Sprint iptal edildiğinde tamamlanmış ve “Bitti” tanımına uyan Ürün İş Listesi maddeleri gözden geçirilir. Eğer teslim edilebilir bir iş parçacığı varsa genelde Ürün Sahibi bunu kabul eder. Tamamlanmamış tüm Ürün İş Listesi maddelerinin büyüklükleri yeniden tahmin edilir ve bu maddeler Ürün İş Listesi’ne geri döner. Bu maddeler üzerindeki iş azalır ve işin yeniden tahmin edilmesi gerekir.

Sprint iptalleri kaynakları tüketir çünkü herkes yeni bir Sprint’e başlamak için Sprint Planlama’da bir araya gelir. Sprint iptalleri, Scrum Takımı için genellikle travmatiktir ve nadir yaşanır.

Sprint Planlama

Sprint içinde yapılacak iş Sprint Planlama’da planlanır. Bu plan tüm Scrum Takımı’nın iş birliğiyle oluşturulur.

Sprint Planlama, bir aylık Sprint için sekiz saatle sınırlanmıştır. Kısa Sprint’ler için etkinlik genelde daha kısadır. Scrum Master, etkinliğin yapılmasını ve katılımcıların etkinliğin amacını anlamasını sağlar. Scrum Master, Scrum Takımı’na etkinliği süresi içinde bitirmeyi öğretir.

Sprint Planlama aşağıdaki sorulara cevap verir:

• Bu Sprint çalışan Ürün Parçası olarak ne teslim edilebilir?
• Çalışan Ürün Parçası nasıl teslim edilecek?

Birinci Konu: Bu Sprint Ne Yapılabilir?

Geliştirme Takımı, Sprint’te geliştirilecek işlevselliği anlamaya çalışır. Ürün Sahibi, Sprint’te tamamlanması gereken Ürün İş Listesi maddelerini ve bu maddelerin ne işe yarayacağını anlatır. Tüm Scrum Takımı Sprint’te yapılacak işi anlamak için iş birliği içinde çalışır.

Bu toplantının girdileri; Ürün İş Listesi, ürünün çalışan son hali, Geliştirme Takımı’nın öngörülen kapasitesi ve Geliştirme Takımı’nın geçmiş performansıdır. Sprint için seçilmiş Ürün İş Listesi maddelerinin sayısını Geliştirme Takımı belirler. Sadece Geliştirme Takımı gelecek Sprint ne kadar iş yapacağını belirler.

Ayrıca Scrum Takımı, Sprint Planlama sırasında Sprint Hedefi’ni oluşturur. Sprint Hedefi, Sprint içerisinde Ürün İş Listesi maddelerinin geliştirilmesiyle ulaşılacak bir hedeftir. Sprint Hedefi, Geliştirme Takımı’na Ürün Parçası’nı neden geliştirdiğine dair rehberlik sağlar.

İkinci Konu: Seçilen İş Nasıl Yapılacak?

Sprint Hedefi’nin belirlenmesi ve Sprint için Ürün İş Listesi maddelerinin seçilmesiyle Geliştirme Takımı, bu işlevselliği Sprint içinde “Bitti” tanımına uyan bir Ürün Parçası haline nasıl dönüştüreceğine karar verir. Sprint için seçilen Ürün İş Listesi maddeleri artı bunları teslim etmek için oluşturulan plan Sprint İş Listesi olarak adlandırılır.

Geliştirme Takımı genellikle sistemi ve Ürün İş Listesi’ni çalışan Ürün Parçası’na dönüştürmek için gerekli işi tasarlayarak başlar. İşin büyüklüğü ya da tahmin edilen eforu değişebilir. Ancak Geliştirme Takımı Sprint Planlama’da Sprint içinde bitirebileceğine inandığı kadar işi planlar. Geliştirme Takımı tarafından Sprint’in ilk günleri için planlanmış iş bu toplantının sonunda bir günlük ya da daha küçük parçalara bölünür. Geliştirme Takımı, Sprint İş Listesi’ndeki işi yönetmek için hem Sprint Planlama hem de Sprint süresince kendi kendini yönetir.

Ürün Sahibi seçilen Ürün İş Listesi maddelerini netleştirmeye ve yapılacak iş miktarının dengelenmesine yardım edebilir. Eğer Geliştirme Takımı Sprint planında çok fazla ya da çok az iş olduğuna karar verirse Ürün Sahibi’yle seçilmiş Ürün İş Listesi maddeleri üzerine pazarlık yapabilir. Geliştirme Takımı aynı zamanda teknik ve alan bilgisine sahip diğer kişileri bilgi vermeleri için toplantıya davet edebilir.

Sprint Planlama’nın sonunda Geliştirme Takımı, Ürün Sahibi’ne ve Scrum Master’a Sprint Hedefi’ne nasıl ulaşacağını ve çalışan Ürün Parçası’nı nasıl geliştireceğini açıklayabilmelidir.

Sprint Hedefi

Sprint Hedefi, Sprint için seçilmiş Ürün İş Listesi’ndeki maddelerin geliştirilmesiyle ulaşılabilecek bir amaçtır. Sprint Hedefi, Geliştirme Takımı’na çalışan Ürün Parçası’nı neden geliştirdiğine dair rehberlik sağlar. Sprint Hedefi, Geliştirme Takımı’na Sprint içinde geliştirilen işlevsellik konusunda esneklik sağlar. Seçilen Ürün İş Listesi maddeleriyle tutarlı bir fonksiyon teslim edilir ki bu fonksiyon Sprint Hedefi olabilir. Sprint Hedefi, Geliştirme Takımı’nın farklı işler yapmasından öte beraber çalışmasıyla oluşturulabilecek herhangi bir şey olabilir.

Geliştirme Takımı çalıştığı süre içinde Sprint Hedefi’ni akılda tutar ve Sprint Hedefi’ne ulaşmak için işlevsellik ve teknoloji geliştirilir. Eğer iş, Geliştirme Takımı’nın beklediğinden farklı çıkarsa Ürün Sahibi’yle Sprint İş Listesi’nin kapsamı konusunda pazarlık yapabilir.

Günlük Scrum

Günlük Scrum, Geliştirme Takımı için 15 dakikayla sınırlı bir etkinliktir. Günlük Scrum, Sprint’in her günü yapılır. Geliştirme Takımı, Günlük Scrum’da gelecek 24 saati planlar. Her gün yapılan bu planlama etkinliği takımın iş birliği içinde çalışmasını ve performansını iyileştirir. Son Günlük Scrum’dan beri yapılan işlerin gözlemlenmesi ve Sprint’te yapılması gereken diğer işlerin öngörülmesiyle iyileştirilme gerçekleştirilir. Günlük Scrum, karmaşıklığı azaltmak için her gün aynı yer ve saatte yapılır.

Geliştirme Takımı, Günlük Scrum’ı Sprint Hedefi’ne doğru olan ilerlemeyi ve Sprint İş Listesi’ndeki işlerin gidişini gözlemlemek için kullanır. Günlük Scrum, Geliştirme Takımı’nın Sprint Hedefi’ne ulaşma olasılığını artırır. Her gün Geliştirme Takımı kendi kendini yöneten bir takım olarak Sprint Hedefi’ne nasıl ulaşacağını ve Sprint sonunda Ürün Parçası’nı nasıl oluşturacağını düşünmelidir.

Toplantının yapısı Geliştirme Takımı tarafından belirlenir ve Sprint Hedefi’ne doğru ilerleme odağında farklı yollarla yapılabilir. Bazı Geliştirme Takımları sorular kullanır, bazı Geliştirme Takımları daha çok konuşma odaklıdır. Aşağıda kullanılabilecek bir örnek var:

• Geliştirme Takımı’nın Sprint Hedefi’ne ulaşması için dün ne yaptım?
• Geliştirme Takımı’nın Sprint Hedefi’ne ulaşması için bugün ne yapacağım?
• Sprint Hedefi’ne ulaşma yolunda benim ya da Geliştirme Takımı’nın önünde bir engel görüyor muyum?

Geliştirme Takımı ya da takım üyeleri sıklıkla Günlük Scrum’dan hemen sonra daha detaylı bir konuşma, adaptasyon ya da yeni bir plan için toplanırlar.

Scrum Master, Geliştirme Takımı’nın toplantıyı yaptığından emin olur fakat Günlük Scrum’ın yapılmasından Geliştirme Takımı sorumludur. Scrum Master, Geliştirme Takımı’na, Günlük Scrum’ı 15 dakika içinde tutmayı öğretir.

Günlük Scrum, Geliştirme Takımı için bir toplantıdır. Eğer başkaları katılırsa, Scrum Master bu kişilerin toplantıyı bölmemelerini sağlar.

Günlük Scrum’lar iletişimi geliştirir, diğer toplantıların sayısını azaltır, geliştirmenin önündeki engellerin belirlenmesini sağlar, karar almayı hızlandırır ve Geliştirme Takımı’nın bilgi seviyesini artırır. Günlük Scrum, gözlem ve adaptasyon için önemli bir toplantıdır.

Sprint Değerlendirme

Sprint Değerlendirme, çalışan Ürün Parçası’nı gözlemlemek ve gerekiyorsa Ürün İş Listesi’ni güncellemek için Sprint’in sonunda yapılır. Sprint Değerlendirme’de Scrum Takımı ve paydaşlar Sprint’te neler yapıldığına dair iş birliği yaparlar. Sprint Değerlendirme ve Sprint içinde yapılan Ürün İş Listesi’ndeki değişikliklerle katılımcılar değeri optimize etmek için sıradaki işin ne olacağına dair iş birliği yaparlar. Bu resmi olmayan bir toplantıdır, durum toplantısı değildir. Çalışan Ürün Parçası’nın sunumu, geri bildirimleri ortaya çıkarma ve iş birliğini artırma amacıyla yapılır.

Bir aylık Sprint’lerde en fazla dört saat olabilir. Daha kısa Sprint’ler için etkinlik genellikle daha kısadır. Scrum Master, etkinliğin yapıldığından ve katılımcıların etkinliğin amacını anladığından emin olur. Scrum Master, dahil olan herkese etkinliği belirlenen süre içinde tutmayı öğretir.

Sprint Değerlendirme aşağıdaki öğeleri içerir:

• Scrum Takımı ve paydaşlar, Ürün Sahibi tarafından davet edilir.
• Ürün Sahibi, hangi Ürün İş Listesi maddelerinin “Bitti”ğini, hangi maddelerin bitmediğini açıklar.
• Geliştirme Takımı, Sprint sırasında nelerin iyi gittiğini, hangi problemlerle karşılaştığını ve bu problemlerin nasıl çözüldüğünü anlatır.
• Geliştirme Takımı, “Bitti” tanımına uyan işleri gösterir ve Ürün Parçası hakkındaki soruları yanıtlar.
• Ürün Sahibi, Ürün İş Listesi’nin son durumunu anlatır. Gerekirse ilerlemeyi baz alarak hedef ve teslim tarihlerini paylaşır.
• Toplantının tüm katılımcıları sıradaki işin ne olacağına dair iş birliği yapar. Böylece Sprint Değerlendirme, gelecek Sprint Planlama için değerli bir girdi sağlar.
• Pazar ya da ürünün potansiyel kullanımındaki değişim sıradaki en değerli işi seçerken incelenir.
• Zaman çizelgesi, bütçe, potansiyel yetenekler ve pazar işlevselliklerin gelecek teslimi ya da ürünün yetenekleri açışından incelenir.

Sprint Değerlendirme’nin sonucu, gelecek Sprint için muhtemel Ürün İş Listesi maddelerinin tanımlandığı gözden geçirilmiş bir Ürün İş Listesi’dir. Ürün İş Listesi, yeni fırsatları karşılamak için en baştan değerlendirilebilir.

Sprint Retrospektif

Sprint Retrospektif, Scrum Takımı’nın kendini gözlemlemesi ve iyileştirme planı oluşturması için bir fırsattır.

Sprint Retrospektif, Sprint Değerlendirme’den hemen sonra sıradaki Sprint Planlama’dan önce yapılır. Bir aylık Sprint’ler için en fazla üç saattir. Daha kısa Sprint’ler için etkinlik genellikle daha kısadır. Scrum Master, etkinliğin yapıldığından ve katılımcıların etkinliğin amacını anladığından emin olur.

Scrum Master, toplantının pozitif ve üretken olmasından sorumludur. Scrum Master, herkese toplantının belirlenen süre içerisinde tutulmasını öğretir. Scrum Master, toplantıya Scrum sürecinin sorumluluğunu alan bir takım üyesi olarak katılır.

Sprint Retrospektif’in amacı:

• Son Sprint’in insanlar, ilişkiler, süreç ve araçlar açısından nasıl geçtiğini gözlemleme
• İyi giden şeylerin ve potansiyel iyileştirmelerin belirlenmesi ve sıralanması
• Scrum Takımı’nın iş yapış şeklindeki iyileştirmelerin uygulanabilmesi için bir plan oluşturma

Scrum Master, Scrum Takımı’nı, Scrum süreç çerçevesi içinde kalacak şekilde geliştirme süreci iyileştirmeleri ve bu süreci daha verimli ve eğlenceli kılacak pratikleri hayata geçirecek iyileştirmeler için cesaretlendirir. Scrum Takımı, her Sprint Retrospektif’te iş sürecini iyileştirerek ya da “Bitti” tanımını geliştirerek ürün kalitesini artırmanın yollarını planlar. Bu, ürünle ya da organizasyonel standartlarla bir çatışma içinde olmayacaksa yapılır.

Sprint Retrospektif sonunda Scrum Takımı gelecek Sprint’te uygulanacak iyileştirmeleri belirlemiş olmalıdır. Gelecek Sprint’te bu iyileştirmeleri uygulama, Scrum Takımı’nın kendi kendini gözlemlemesinin bir adaptasyonudur. Tabi ki iyileştirmeler her zaman gerçekleştirilebilir fakat Sprint Retrospektif, gözleme ve adaptasyona odaklanmak için resmi bir fırsat sağlar.

Scrum Araçları

Scrum araçları, şeffaflığı sağlamak için iş, değer, gözlem ve adaptasyon için fırsatlar sağlar. Scrum tarafından tanımlanan araçlar önemli bilgilerin şeffaflığını en yüksek seviyeye çıkarmak için tasarlanmıştır böylece herkesin araçtan anladığı şey aynı olabilir.

Ürün İş Listesi

Ürün İş Listesi, üründe olması istenen her şeyin sıralandığı bir listedir. Üründe yapılacak değişiklik ihtiyaçlarının bulunduğu tek kaynaktır. Ürün Sahibi, Ürün İş Listesi’nden, içeriğinden, erişilebilirliğinden ve sıralanmasından sorumludur.

Bir Ürün İş Listesi asla tam değildir. Bir Ürün İş Listesi ilk oluşturulduğunda bilinen ve en iyi anlaşılmış ihtiyaçları gösterir. Ürün İş Listesi, ürün ve ürünün kullanılacağı ortam evrimleştikçe evrimleşir. Ürün İş Listesi dinamiktir; Ürün İş Listesi, ürünün ihtiyacı olan uygun, rekabetçi ve kullanışlı şeyi belirlemek için sürekli değişir. Bir ürün var oldukça, bu ürünün Ürün İş Listesi’de var olur.

Ürün İş Listesi, gelecek teslimlerde ürün üzerinde geliştirilecek tüm özellikleri, fonksiyonları, ihtiyaçları, iyileştirmeleri ve düzeltmeleri içerir. Ürün İş Listesi maddeleri, tanım, sıra, büyüklük tahmini ve değer özelliklerine sahiptir. Ürün İş Listesi maddeleri, bir madde “Bitti”ğinde tamamlandığını kanıtlayan test tanımlarını da içerir.

Ürün kullanıldıkça, değer kazandıkça ve pazar geri bildirim sağladıkça Ürün İş Listesi daha büyük ve yorucu bir liste haline dönüşür. İhtiyaçlar sürekli değişir bu nedenle Ürün İş Listesi sürekli yaşayan bir araçtır. İş ihtiyaçları, pazar şartları ya da teknoloji değişiklikleri Ürün İş Listesi’nde değişikliklere neden olabilir.

Birden fazla Scrum Takımı sıklıkla aynı ürün üzerinde beraber çalışırlar. Bir Ürün İş Listesi ürün hakkında çalışılacak işi tanımlamak için kullanılır. Bir Ürün İş Listesi’ndeki maddeler gruplanır ve daha sonra takımlar bu maddeleri çekerler.

Ürün İş Listesi detaylandırma, iş maddelerine detay, tahmin ve sıra ekleme eylemidir. Bu, Ürün Sahibi’nin ve Geliştirme Takımı’nın Ürün İş Listesi maddeleri üzerine birlikte çalıştığı sürekli devam eden bir süreçtir. Ürün İş Listesi detaylandırma boyunca iş maddeleri gözden geçirilir ve değiştirilir. Scrum Takımı, detaylandırma aktivitesinin nasıl ve ne zaman biteceğine karar verir. Detaylandırma aktivitesi Geliştirme Takımı’nın kapasitesinin %10’undan daha fazlasını tüketmez. Ürün İş Listesi maddeleri, Ürün Sahibi tarafından ya da onun inisiyatifiyle her zaman güncellenebilir.

Yüksek öncelikli Ürün İş Listesi maddeleri, düşük öncelikli maddelere göre genellikle daha net ve daha detaylıdır. Doğruya daha yakın büyüklük tahminleri, işin netliğinin ve detayının yüksek olduğu durumlarda yapılabilir, sıralamada aşağıda bulunan maddelerin detayı azdır. Geliştirme Takımı’nı gelecek Sprint’te meşgul edecek Ürün İş Listesi maddeleri detaylandırılmıştır böylece herhangi bir madde Sprint süresi içinde “Bitti” durumuna getirilebilir. Geliştirme Takımı tarafından bir Sprint içinde “Bitti” durumuna getirilebilen Ürün İş Listesi maddeleri Sprint Planlama içinde seçime “Hazır” sayılırlar. Ürün İş Listesi maddeleri yukarıda tanımlanan detaylandırma aktiviteleriyle genellikle bu derece şeffaflığı kazanırlar.

Geliştirme Takımı, işlerin büyüklüklerinin tahmin edilmesinden sorumludur. Ürün Sahibi, Geliştirme Takımı’na işin büyüklüğünün anlaşılması ve seçim tercihinin yapılması için yardımcı olabilir fakat işi yapacak kişiler son tahmini yapar.

Hedeflere Doğru İlerlemeyi Gözlemleme

Zaman içinde herhangi bir noktada bir hedefe ulaşabilmek için kalan iş toplanabilir. Ürün Sahibi, en azından her Sprint Değerlendirme’de kalan işlerin toplamını takip eder. Ürün Sahibi, kalan bu toplam iş miktarını ve daha önceki Sprint Değerlendirmelerde belirlenen kalan iş miktarını karşılaştırır ve hedefe doğru ilerlemeyi gözlemler. Bu bilgi tüm paydaşlar için şeffaf hale getirilir.

Tahmin edilen ilerlemenin öngörülebilmesi için farklı pratikler kullanılabilir, örneğin burn-down, burn-up grafikler ya da kümülatif diyagramlar. Bu araçlar kullanışlı olduklarını kanıtlamıştır. Ancak bu araçlar deneyciliğin yerini alamaz. Karmaşık ortamlarda ne olacağı bilinmezdir. Ancak hali hazırda olmuş olan gelecekle ilgili kararlar almak için kullanılabilir.

Sprint İş Listesi

Sprint İş Listesi, Sprint için seçilmiş Ürün İş Listesi maddelerinden oluşan bir küme, artı çalışan Ürün Parçası’nın teslim edilmesi ve Sprint Hedefi’nin gerçekleştirilmesi için oluşturulan plandır. Sprint İş Listesi, Geliştirme Takımı’nın sıradaki Ürün Parçası’nda hangi işlevselliklerin olacağına ve bu işlevselliği “Bitti” tanımına uyan bir şekilde teslim etmek için gerekli olan işe dair ön görüsüdür.

Sprint İş Listesi, Geliştirme Takımı’nın Sprint Hedefi’ne ulaşmak için yapılmasını gerekli gördüğü tüm işi görünür kılar. Sprint İş Listesi, sürekli iyileştirmenin devam etmesi için bir önceki retrospektif toplantısında belirlediği önceliği yüksek en az bir süreç iyileştirme maddesi içerir.

Sprint İş Listesi, ilerlemenin Günlük Scrum’da anlaşılabileceği kadar detaylı bir plandır. Geliştirme Takımı, Sprint İş Listesi’ni Sprint boyunca değiştirebilir ve Sprint İş Listesi, Sprint yaşanırken ortaya çıkar. Bu ortaya çıkma, Geliştirme Takımı plan üzerinde çalıştıkça ve Sprint Hedefi’ne ulaşmak için yapılması gereken işi öğrendikçe gerçekleşir.

Yeni bir iş gerektiğinde Geliştirme Takımı, bu işi Sprint İş Listesi’ne ekler. İş yapıldıkça ya da tamamlandıkça tahmin edilen kalan iş miktarı güncellenir. Plandaki öğelerden birinin gereksiz olduğuna karar verilirse bu öğe silinir. Sprint içinde sadece Geliştirme Takımı, Sprint İş Listesi’ni değiştirebilir. Sprint İş Listesi’nin görünürlüğü yüksektir, Sprint süresince Geliştirme Takımı’nın başarmayı planladığı işin gerçek zamanlı resmidir ve sadece Geliştirme Takımı’na aittir.

Sprint’in İlerleyişini Gözlemleme

Sprint içinde herhangi bir noktada Sprint İş Listesi’nde kalan iş toplanabilir. Geliştirme Takımı, Sprint Hedefi’ne doğru ilerleyişini görmek için kalan işin toplamını en azından her Günlük Scrum’da takip eder. Geliştirme Takımı, Sprint boyunca kalan işi takip ederek ilerleyişini yönetebilir.

Ürün Parçası

Ürün Parçası, Sprint içinde tamamlanan Ürün İş Listesi maddelerinin ve önceki Sprint’lerde geliştirilen ürün parçalarının değerlerinin toplamıdır. Bir Sprint’in sonunda yeni Ürün Parçası “Bitti” tanımına uymalıdır. Bunun anlamı Ürün Parçası’nın kullanılabilir durumda ve Scrum Takımı’nın “Bitti” tanımını karşılıyor olmasıdır. Ürün Parçası, Sprint sonunda deneyciliği destekleyen gözlemlenebilir, bitmiş iştir. Ürün Parçası, Ürün Sahibi’nin teslim edilme kararına bakılmaksızın kullanılabilir durumda olmalıdır

Araçların Şeffaflığı

Scrum şeffaflığa dayanır. Değeri optimize etmek ve riski kontrol etmek için alınan kararlar araçların algılanan durumuna dayanır. Kararların alındığı temellerin güveni şeffaflığın ölçüsüne dayanır. Şeffaflık azsa alınan kararlar kusurlu, değer kayıp olabilir ve risk artabilir.

Scrum Master, Ürün Sahibi, Geliştirme Takımı ve dahil olan diğer paydaşlarla araçların şeffaflığını anlamaları için beraber çalışmalıdır. Şeffaflığın olmadığı durumlarla başa çıkmak için pratikler vardır; Scrum Master, şeffaflığın olmadığı durumlarda en uygun pratiğin uygulanabilmesi için herkese yardım etmelidir. Bir Scrum Master şeffaflığın olmadığını, araçları, tekrar eden durumları gözlemleyerek, söylenenleri iyi dinleyerek, beklenen ve gerçekleşen sonuçlar arasındaki farkları analiz ederek belirleyebilir.

Scrum Master’ın işi, Scrum Takımı ve organizasyonla beraber çalışarak araçların şeffaflığını artırmaktır. Bu iş genellikle öğrenme, ikna etme ve değişimi içerir. Şeffaflık bir gecede oluşmaz daha çok bir yolculuktur.

“Bitti” Tanımı

Bir Ürün İş Listesi maddesi ya da Ürün Parçası “Bitti” olarak ifade edildiğinde herkes “Bitti” ifadesinin ne anlama geldiğini anlamalıdır. Ancak “Bitti” tanımı Scrum Takımları arasında farklılık gösterebilir. Scrum Takımı üyeleri, şeffaflığın sağlanabilmesi için bir işin tamamlandığına dair ortak bir anlayışa sahip olmalıdır. Bu “Bitti” tanımı Scrum Takımı içindir ve Ürün Parçası’nı geliştirmek için gerekli olan işin tamamlanmasına yardımcı olması için kullanılır.

Aynı tanım Sprint Planlama’da kaç Ürün İş Listesi maddesi seçilebileceğine dair Geliştirme Takımı’na rehberlik eder. Her Sprint’in amacı potansiyel olarak kullanılabilir işlevselliklerden oluşan Ürün Parçası teslim etmektir. Bunu gerçekleştirebilmek Scrum Takımı’nın kullandığı “Bitti” tanımıyla ilişkilidir.

Geliştirme Takımları, her Sprint Ürün Parçası teslim eder. Bu Ürün Parçası kullanılabilirdir yani Ürün Sahibi, bu Ürün Parçası’nı hemen teslim etmeyi seçebilir. Eğer bir Ürün Parçası için “Bitti” tanımı bir geliştirme organizasyonun kurallarının, standartlarının ya da kılavuzlarının bir parçasıysa her Scrum Takımı’nın “Bitti” tanımında en azından bu alanlar ortak olmalıdır.

Eğer bir Ürün Parçası için “Bitti” tanımı geliştirme organizasyonunun kurallarından biri değilse Geliştirme Takımı ürün için uygun bir “Bitti” tanımı geliştirmelidir. Eğer bir sistem ya da ürün üzerinde çalışan birden fazla Scrum Takımı varsa tüm Geliştirme Takımları karşılıklı bir anlaşmayla “Bitti” tanımını oluşturmalıdırlar.

Her Ürün Parçası, önceki ürün parçalarına bir katkıdır ve tamamıyla test edilmiştir, tüm Ürün Parçaları’nın beraber çalışması sağlanmıştır.

Scrum Takımı olgunlaştıkça “Bitti” tanımlarının yüksek kalite için daha sıkı kriterleri içerecek şekilde genişlemesi beklenir. Yeni tanımlar önceleri geliştirilen Ürün Parçaları’ndaki işleri kapsamayabilir. Herhangi bir ürün ya da sistem, üstünde yapılacak işler için standart bir “Bitti” tanımına sahip olmalıdır.

Son Not

Scrum ücretsizdir ve bu kılavuzda anlatılmaktadır. Scrum’daki roller, etkinlikler, araçlar ve kurallar değiştirilemez. Scrum’ın bazı parçalarını uygulamak mümkündür fakat bu Scrum olmaz. Scrum bütün olarak var olabilir ve diğer teknikler, metotlar ve pratikler için bir konteynır olarak işleyebilir.

Teşekkür

Kişiler

Scrum’a katkıda bulunan binlerce kişi arasında başlangıçtan beri yardımı dokunanları ayırmalıyız:

Jeff Sutherland, Jeff McKenna ve John Scumniotales beraber çalıştı. Ken Schwaber, Mike Smith ve Chris Martin ile beraber çalıştı ve sonra hepsi bir araya gelerek çalıştı. Sonraki yıllarda birçok kişi katkıda bulundu ve onların yardımı olmadan Scrum bugün ki durumunda olmazdı.

Tarihçe

Ken Schwaber ve Jeff Sutherland 1995 yılındaki OOPSLA konferansında beraber yaptıkları sunuma kadar Scrum üzerine çalıştı. Bu sunumda, Ken’in ve Jeff’in geçmiş yıllarda kazandıkları öğrenimleri belgelendi ve Scrum’ın ilk defa resmi olarak herkese açık hale getirildi.

Scrum’ın tarihçesi başka bir yerde anlatıldı. Scrum’ın ilk defa denendiği ve olgunlaştırıldığı yerler olan Individual Inc., Newspage, Fidelity Investments ve IDX’e (şimdi GE Medical) teşekkür ediyoruz.

Scrum Kılavuzu, 20 yılı aşkın süredir Jeff Sutherland ve Ken Schwaber tarafından geliştirilen, evrimleştirilen ve korunan Scrum’ı belgeler. Diğer kaynaklar Scrum çerçevesini tamamlayan şablonlar, süreçler ve iç görüler sağlar. Bu kaynaklar üretkenliği, değeri, yaratıcılığı ve sonuçlardan memnuniyeti artırabilir.

Kavramlar Sözlüğü

Çevirenin Sözü

Scrum Kılavuzu’nun ilk çevirisini 2012 yılında yapmıştım. Çeviriyi yaptığım dönemde Scrum konusundaki bilgim ve tecrübem sınırlıydı. O günden bugüne 4 kitap çevirisi yaptım, 70’ten fazla makale yazdım ve 6 yıldır aktif olarak tecrübe ediyorum. Zaman içinde Scrum Kılavuzu iki defa güncellendi. Bu çeviriye güncellemeleri de ekledim. Çevirinin bu sürümünde sadece Scrum Kılavuzu’nda yapılan güncellemeler değil bilgi ve tecrübelerimde olan güncellemelerde bulunuyor.

Umarım daha anlaşılır ve basit bir çeviri olmuştur. İyileştirilmesi gerektiğini düşündüğünüz bölümler hakkında lütfen geri bildirimde bulunun. Bu çeviriyi hep beraber daha iyi bir seviyeye getirebiliriz. site@yilmazcihan.com eposta adresinden benimle iletişime geçebilirsiniz.

Sevgiler…

Cihan Yılmaz

Ocak 2018 – İstanbul