Scrum Roller ve Sorumluluklar

http://www.slideshare.net/cihanyilmaz88/scrum-roller-ve-sorumluluklar-62357947

Bu sunumda sizlere Scrum Roller ve Sorumluluklar nelerdir konusunu özetlemeye çalışacağım. Makaleyse daha derin ve gerçek hayattan bilgiler isteyenler için yazıldı.

Scrum, felsefe olarak deneyciliğe dayanır. Scrum’ın doğru şekilde işleyebilmesi için Şeffaflık, Gözlem ve Adaptasyon olmalıdır.

Scrum’da üç rol bulunur. Bu roller, Ürün Sahibi, Geliştirme Takımı ve Scrum Master’dır. Şimdi bu üç rolün sahip olduğu sorumluluk nelerdir konusuna değineceğim.

Ürün Sahibi’nin Sorumlulukları

İş Listesini yönetir. Birincil önceliği İş Listesi’ni yönetmektir. İş Listesi’ni yönetmek demek, ürünü yönetmek demektir. Ürünle ilgili yapılacak bütün geliştirme İş Listesi’nde bulunur. Ürün Sahibi, İş Listesi’ni yönetirken şunlara dikkat eder:

• Yatırım Getirisi
• Risk
• İş Değeri
• Teknoloji

İş Listesi’nin sahibi Ürün Sahibi’dir. İş Listesi herkes tarafından erişilebilir ve anlaşılabilir olmalıdır.

Ürün Sahibi, Geliştirme Takımı ve müşteri arasındaki iletişimi gerçekleştirir. Müşteri ürünle ilgili bir özellik hakkında konuşmak istediğinde ilk önce Ürün Sahibi’yle iletişime geçmelidir. Bu müşterinin Geliştirme Takımı’yla hiç iletişime geçmeyeceği anlamına gelmez. Gerekli durumlarda elbet müşteriler ve Geliştirme Takımı üyeleri görüşebilirler.

Değeri Maksimize Etme

Ürün Sahibi’nin bir diğer sorumluluğuysa Geliştirme Takımı’nın yaptığı işin değerini maksimize etmektir. Bunu nasıl yapar; büyük bir organizasyon içinde Ürün Sahibi rolünü üstlenen kişi ilgili iş birimleriyle görüşüp geliştirilen ürünün özelliklerini anlatmak ve ürünün kurum için ne kadar değerli olduğunu ve değer yarattığını anlatmaktır. Daha küçük şirketlerdeyse Ürün Sahibi pazar araştırmasına girebilir, ürünü daha çok kişiye nasıl ulaştırabileceğini düşünmelidir. Aynı şekilde ürünü değerli kılan özellikleri ön plana çıkarmalıdır.

Teslim Planlaması

Ürün Sahibi, sürüm yönetiminden sorumludur. Geliştirme Takımı her Sprint’te ürüne yeni özellikler ekleyebilir. Bu özelliklerin son kullanıcıya ne zaman ulaştırılacağına Ürün Sahibi karar verir. Örnek bir proje düşünelim. Bir B2B projesi, projenin ilk birkaç ayında sadece sipariş modülü tamamlanmış olsun. Ürün Sahibi sadece sipariş modülüne sahip bu ürünü biran önce piyasaya sürmek isteyebilir. Çünkü rakiplerine karşı pazar avantajı elde edebileceğini düşünüyordur. Bir başka fikirse şu olabilir. Bu yeni bir üründür ve daha olgunlaşmamıştır. Ayrıca sadece bir sipariş modülüne sahip bu ürün hedef müşterinin isteklerini karşılayamamaktadır. Son kullanıcıdan olumsuz geribildirimler almak yerine ürünün diğer modüllerininde eklenmesini beklemek isteyebilir. Bu karar Ürün Sahibi tarafından verilmelidir.

Sprint’i İptal Etme

Sprint’i iptal yetkisine sahiptir. Hızla değişen ortamlarda bir Sprint’e alınan işlerin iş birimi ya da son kullanıcı için değeri kalmamış olabilir. Ürün Sahibi bunu görüp Sprint’i iptal etmek isteyebilir. Bir başka durumsa Sprint’e alınan işlerden çok daha acil bir konunun ortaya çıkmasıdır. Örneğin yasal bir zorunluluk, değerlendirilmesi gereken bir pazar avantajı gibi… Bunlar içinde bulunulan Sprint’te yapılan işlerden daha değerliyse Ürün Sahibi, Sprint’i iptal etmek isteyebilir. Hızlıca yeni bir planlama yapılır ve yeni Sprint’e başlanır. Bu durum çok nadir olarak gerçekleşebilir.

Sprint Değerlendirme Toplantılarının Sahibi

Sprint Değerlendirme Toplantıları’nın sahibidir. Özellikle Scrum’a yeni başlayan takımlarda genel algı şu yöndedir. Scrum Master bütün toplantıları düzenler. Hayır! Arkadaşlar Scrum Master hiç bir toplantıyı düzenlemekle sorum değildir. Sprint Değerlendirme Toplantısı’nın asıl sahibi Ürün Sahibi’dir. Ürün Sahibi, iş birimlerini, ürün sponsorlarını, son kullanıcıları, operasyon ekiplerini, ürün hakkında fikir verebilecek kişileri ve Geliştirme Takımı’nı bu toplantıya davet etmelidir. Toplantıda Geliştirme Takımı, geliştirilen özellikler hakkında bilgi verebilir fakat sorumluluk Ürün Sahibi’ndedir.

Ürün Sahibi Kim Değildir?

Geliştirme Takımı’nın yöneticisi değildir. Eski proje yöneticisi, takım lideri, kaynak yöneticisi rolüne sahip kişilerin ilk refleksi Geliştirme Takımı’nı yönetmeye çalışmalarıdır. Bu yapılmamalıdır! Geliştirme Takımı kendi kendini yönetir. Ürün Sahibi, teknik bir geçmişe sahip olabilir. Bu, hangi işi kimin yapacağına karışabileceği anlamına gelmez. Ayrıca bu, hangi işin nasıl yapılacağına -bakın ne yapılacağına demiyorum- karışabileceği anlamına gelmez. Teknik bir geçmişe sahip olması ve teknik anlamda deneyimli olması nedeniyle belki fikir sunabilir, önerilerde bulunabilir fakat sadece bu kadar. Bir işin nasıl yapılacağına o işi yapanlar karar verebilir ve sorumluluk onlarındır.

Ürün Sahibi, iş, görev ataması yapamaz. Yine yukarıdaki örnekle gidersek geçmişte takım liderliği, yöneticiliği ya da proje yöneticiliği yapmış kişiler buna çok meyillidir. İş Listeleri’nde ilgili işi kimin yapacağına dair bir alan sürekli olarak bulundurmak isterler. Scrum Master ve Geliştirme Takımı buna karşı çıkmalıdır. İşler kişiler üzerinden yapılmamalıdır, Geliştirme Takımı’nın tamamı düşünülmelidir.

İşin nasıl yapılacağına karışamaz!

Durum raporu isteyemez!

Günlük Scrum’lara katılamaz. Bu her zaman bir tartışma konusu olmuştur. Eski yöneticinin, Günlük Scrum Toplantılarına katılması Geliştirme Takımı’nı stres altına sokuyorsa ve Geliştirme Takımı üyeleri şeffaflığı koruyamıyorsa katılmamalıdır. Eğer şeffaflık bozulmuyorsa elbet katılabilir fakat konuşmadan ve işlere karışmadan sadece Geliştirme Takımı üyelerini dinlemesi iyi bir pratiktir. Aynı şekilde toplantının sonunda birkaç dakikalığına Geliştirme Takımı üyelerine bilgi verebilir. Bu şeffaflığın artmasına yardımcı bile olabilir. Burada dikkat edilmesi gereken nokta şeffaflıktır.

Sprint Değerlendirme Öncesi

Sprint içinde bitirilen işleri ilk defa Sprint Değerlendirme Toplantısı’nda gören kişi değildir! Yeni başlayan takımlarda ve özellikle iş biriminden ya da müşteri temsilcisi olarak Ürün Sahibi olan kişilerde Sprint içinde Geliştirme Takımı’yla etkileşimi, iletişimi enaz seviyede tutma davranışı ortaya çıkar. Elbet sürekli Geliştirme Takımı’yla yan yana olmamalıdır fakat toplantıdan toplantıya da görüyor olmamalıdır. İş biriminden ya da müşteriden gelen kişiler Bilgi Teknolojileri ekipleri işlerini bizim üzerimize yıkmaya çalışıyorlar şeklinde düşünürler. Bu yanlıştır! Ürünü kullanacak kişi işin sahibidir ve ürünü sahiplenmelidir. Bilgi Teknolojileri sadece hizmet sağlayan bir organizasyondur. Ne hizmet istendiğiyse hizmeti isteyen kişiye aittir. Bu hizmetin nasıl sağlanacağıysa Bilgi Teknolojileri organizasyonunun sorumluluğundadır.

Geliştirme Takımı’nın Sorumlulukları

Kendi kendini yönetir

Geliştirme Takımı, push yöntemiyle çalışmaz aksine pull yöntemiyle çalışır. Bir işin kendisine atanmasını beklemez. İş kendisi alır ve geliştirir.

Çapraz fonksiyoneldir

İşin beklenen işlevselliği karşılaması tamamıyla Geliştirme Takımı’nın sorumluluğundadır. Geliştirme Takımı, bir Sprint’e alınan bütün işleri tamamlayacak özelliklere sahip kişilerden oluşturulur.

Geliştirici dışında ünvan tanımaz. Geliştirme Takımı içinde alt takımlar oluşturulamaz. Geliştirme Takımı üyeleri farklı yetkinliklere sahip olabilir. Eski ünvanları analist, testçi, DBA vs. olabilir. Geliştirme Takımı’nda yazılım geliştirme süreçlerinde bulunan herkes geliştiricidir.

Geliştirme Takımı üyeleri T şeklinde yetkinliklere sahiptir. T’nin anlamı aşağıya doğru uzanan çizgi yani kişinin uzmanlık seviyesi olan konular kadar T’nin üst çizgisi yani uzman olmadığı ama yetkinliği olduğu konuların bulunmasıdır. Yani bir geliştirici Java konusunda uzman olabilir fakat C# konusunda da bilgi sahibi olabilmelidir. Takıma C# ile ilgili bir konu geldiğinde çözüme yardımcı olabilmesi beklenir. Aynı şekilde eskiden sadece test yapan bir kişi veritabanıyla ilgili bir konu olduğunda bunun çözümüne yardımcı olabilmelidir.

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

Geliştirme Takımı üye sayısı 3-9 arasında değişebilir, ideal takımlarsa 5-7 arasındadır. Geliştirme Takımı 5 kişiden az olduğunda etkileşim ve iletişim çok az olur. İnsanlar zaten sürekli beraberiz daha fazla konuşacak birşey yok diye düşünüp, iletişimi azaltırlar ve zamanlar bitirirler. Buda yaratıcılığın ve problem çözme yeteneğinin ölmesi anlamına gelmektedir. Kendimden örnek vermek istiyorum. Karşılaştığım problemlerin çözümünde genel sonuca şöyle ulaşıyorum. Bir takım arkadaşıma yaşadığım problemi ve çözümü için denediğim yolları anlatmaya başlıyorum, bitirdiğimdeyse gerçek çözüme ulaştığımı birçok defa gördüm. Elbet konuşmayı sevmeyen insanlar vardır, hele ki yazılım geliştiriciler içinde bu oran çoktur.

Unutmayın arkadaşlar, iletişim yaratıcılığı artırır. Tek başınıza bir günde çözebileceğiniz bir problemi biriyle iletişime geçip birkaç dakikada çözebilirsiniz. Bence bu çok değerli! Geliştirme Takımı üye sayısı 7’den büyük olduğundaysa iletişim takip edilemeyecek kadar karmaşıklaşmaya başlar. Bu, büyük takımların birçok dezavantajından sadece birisidir. Ayrıca üye sayısı arttığı için kişiler arasında gruplaşmada gerçekleşir. Bu yine iletişime zarar verir. Büyük takımların kendi kendini yönetmesi zordur. Toplantıları bile uzun ve verimsiz olur. Geliştirme Takımı üye sayısını optimumda tutmak çok iyi bir pratiktir.

Ürünün geliştirilmesiyle ilgili tüm sorumluluk Geliştirme Takımı’na aittir!

Scrum Master’ın Sorumlulukları

Scrum Takımı’nın Scrum teori, pratik ve kurallarına bağlı kalmasından sorumludur.

Hizmetkar liderdir. Bunu pratiğe dökersek şu demektir: Ürün Sahibi, İş Listesi Maddelerini nasıl oluşturacağını bilmiyor olabilir. Scrum Master, Ürün Sahibi’ne öğreterek hizmet eder. Geliştirme Takımı’nın önüne çıkan engelleri kaldırarak hizmet eder. Örneğin test ortamınızda kullandığını ana bilgisayar çökmüştür ve operasyon ekipleri tarafından ayağa kaldırılması gerekmektedir. Operasyon ekipleri yoğunluklarından dolayı bu işi gerileri atmaktadır. Scrum Master, operasyon ekipleriyle iletişime geçip test bilgisayarının biran önce ayağa kaldırılmasını sağlayarak Geliştirme Takımı’na hizmet eder.

Anlaşmazlıklarda ara bulucudur. Genellikle yaşanan durum şöyledir: Ürün Sahibi, bir Sprint içinde olabildiğince çok iş yaptırmak ister, Geliştirme Takımı’ysa yaptığı işi kaliteli yapmak ister ve bir Sprint’e daha az iş alarak fakat kaliteli iş çıkararak yoluna devam etmek ister. Burada Scrum Master araya girip Ürün Sahibi’nin neyi hedeflediğini Geliştirme Takımı’na açıklamasını söylemelidir. Geliştirme Takımı’ysa yaşanacak Teknik Borcun ileride karşılarına çıkabileceğini Ürün Sahibi’ne anlatması gerekir. Ürün Sahibi bu riski göze alıp ilerleyen Sprint’lerde Geliştirme Takımı’na Teknik Borcun ödenmesi için zaman verebileceğini söyleyerek ikna etmeye çalışabilir. Bu baskıyla olmamalıdır, mantık çerçevesi içinde gerçekleşmelidir. Scrum Master bu tartışma için gerekli ortamı oluşturmakla sorumludur.

Scrum Master, Çeviklik ve Scrum konusunda sürekli gelişim gösteren kişidir.

Scrum Master, Ürün Sahibi’ne, Geliştirme Takımı’na ve bulunduğu kuruma hizmet eder. Hizmetleri aşağıdaki gibi özetlenebilir.

Ürün Sahibi’ne Hizmeti

• Etkili İş Listesi yönetimi
• Deneysel ortamda ürün planlaması
• Yatırım Getirisini en yükseğe çıkarma
• Kısa ve net İş Listesi Maddeleri oluşturma
• Çevikliği öğretme ve uygulamasına yardımcı olma
• İhtiyaç durumunda aktiviteleri gerçekleştirme, Sprint Değerlendirme Toplantısı’nın asıl sahibi Ürün Sahibi’dir demiştim. Ürün Sahibi, yoğun olduğunda bu konuda Scrum Master’dan yardım isteyebilir.

Geliştirme Takımı’na Hizmeti

• Kendi kendini yönetmede koçluk
• Çapraz fonksiyonel olmada koçluk
• Engelleri kaldırma
• İhtiyaç durumunda aktiviteleri gerçekleştirme. Sprint Planlama Toplantısı’nın asıl sahibi Geliştirme Takımı’dır. Yine Ürün Sahibi örneğinde olduğu gibi Geliştirme Takımı üyeleri bu toplantıyı Scrum Master’ın düzenlemesini isteyebilir, bu konuda yardım bekleyebilir.
• Yüksek değerli ürünü oluşturmaya yardım
• Çevikliği ve Scrum’ı öğretme ve uygulamada yardım

Kuruma Hizmeti

• Çevikliğin anlaşılmasında, Scrum’ın uygulanmasında organizasyona koçluk
• Scrum Pratiklerinin organizasyon seviyesinde yaygınlaşmasına yardım
• Organizasyon içinde bulunan diğer paydaşların, yöneticileri, müdürlerin, iş birimlerinin, müşterilerin, son kullanıcıların, operasyon birimlerinin deneysel ürün geliştirmeyi anlamasına yardım
• Scrum Takımı’nın verimliliğini artırma
• Organizasyonda bulunan diğer Scrum Master’lar ile bir araya gelip tecrübelerini paylaşma, iyi pratiklerin yaygınlaşmasını sağlama

Scrum roller ve sorumluluklar konularını kısaca anlatmak istediğim bir sunum hazırlamıştım. Sadece sunum yetmez birkaç sözcükle de gerçek hayattan örnekleri paylaşmak istedim. İşinize yaraması dileğiyle, aklınıza takılan her konuda sorularınızı bekliyorum.