Scrum

Scrum (engl. "itişip kakışma“), yazılım geliştirme ve yazılım Mühendisliği'nde bir uygulama geliştirme çerçevesidir. Atik yazılım geliştirme yöntemi olarak çevik yönetim ve proje yönetimi'nde karmaşık bir ortamda ürünleri geliştirmek, sunmak ve sürdürmek için bir çerçevedir. "Hamleci yaklaşım" şeklinde bir çeviri önerilmiştir. . Bu geliştirme çerçevesinin temel özelliği gözlemci, geliştirmeci ve tekrara dayalı olmasıdır. Birçok modern yazılım projesinin oldukça karmaşık olduğu ve en baştan tümünü planlamanın zor olacağı şeklindeki bir varsayımdan hareket eder. Bu karmaşıklığı üç ilke ile azaltmaya çalışır.

Amaç başlangıçta hayal edilen ve tasarlanana uyan bir ürünün, hızlı, ucuz ve kaliteli şekilde üretilmesidir. Tasarlanan ürünün gerçekleştirilmesi, müşteri/kullanıcı tarafından mümkün olduğunca detaylı şekilde hazırlanmış bir talepler listesinin aşama aşama gerçekleştirilmesi biçiminde yapılmaz. Bunun yerine müşteri/kullanıcı tarafından istenilen ve tanımlanan işlevler, iki ya da dört haftalık "Sprint" adı verilen dönemler içerisinde geliştirilir ve yeniden gözden geçirilir. Bu kullanıcı bazlı gereksinim tanımı Kullanıcı Hikayesi olarak nitelenir ve özellikler defterinde yer alır. Her Sprint sonunda yazılımın fonksiyonel bir parçası bitmiş ve müşteriye teslim edilebilir bir durumda olur. Scrum Çevik yazılım geliştirme prensiplerini hayata geçiren bir yöntemdir.

Ürün Sahibi stratejik ürün geliştirmeden sorumludur. Sorumluluğu net bir ürün vizyonunun Tasarımı, iletişimi, özelliklerin tanımı ve önceliklendirme, teslim edilen sprintin işlevselliği ve kabul edilebilir olup olmadığına karar verme ve şirketin ekonomik faydasına uygun ürün tasarımı ve ana amaçları belirler. Yalnızca o teslimat, işlevsellik ve maliyet gibi kararlardan sorumludur.

Ürün Sahibi ürün özelliklerinin tanımlaması işlemini Ürün Gereksinimini (Product Backlog) kullanır ve yazılım Takımı ile birlikte çalışarak kullanıcı hikâyelerini (User Stories) taşır ve kullanıcı bazlı işlevsellikleri ifade eder. Aldığı kararlar bağlayıcıdır ve iptal edilemez.

Ürün Sahibi ya da proje sorumlusu son kullanıcının bakış açısını üstlenir ve yazılım gelişimini kontrol edip yazılımcılar için hazır bulunur. XP metodunun tersine projenin tek sorumlusudur 'yolculuk nereye' (Pichler 2008) .

Yazılım ekibinin görevi ürün sahibinin taleplerine ve sıralamasına uygun ürünün işlevselliğini sağlamak ve belirlenen kalite standartlarına uymak koşuluyla ürünü teslim etmektir. Ne kadar ve hangi işlevlerin sprinte dahil olacağına kendileri karar verirler.

Scrumda geliştirme takımı bir ekip olarak algılanır ve iyi ya da kötü sonuçlar takım elemanlarına çıkartılmaz bilakis takımı bir birim olarak algılar. Bir takım 5-9 kişiden oluşur.

Scrum takım içinde rol dağılımıyla ilgilenmez. Belirtildiği gibi Scrum bir yönetim metodudur. Tabii ki bütün roller ya da daha doğrusu yetenekler başarılı bir proje gelişimi için hazır olmak zorundadır.

Olası engeller: Takım içindeki iletişim eksikliği, kişisel çelişkiler, takım ve ürün sahibi arasındaki iletişim, dış kaynaklı rahatsızlıkların (ek işlevler gibi) giderilmesi.

Scrum ustası yazılım takımına karşı yürütme yetkisi vardır ancak şeflik yetkisi yoktur bu anlamda ne hüküm verebilir ne de disiplin kovuşturması yapabilir (Servant Leaders > Hizmetkar Liderlik).

Scrum ustasının kim olacağının belirlenmesinin en ideal yolu yazılım takımı tarafından seçilmesidir. Pratikte bu pek mümkün olmayabilir .Çünkü iş yapan firmalar Scrum takımının Scrum metodolojisine tam uyum sağlamaları için Scrum konusunda deneyimli bir personeli proje başında belirleyebilir.

Özet olarak Scrum ustası (Change Agent): Süreçten sorumlu, takımın arkadaşı ve yardımcısı, sürecin doğruluğunun denetleyicisi, takım ile birebir bağlantılı ve Takımın yanında çalışır.

Yönetici de kullanıcı ve müşteri gibi Scrum ekibine az oranda tabiidir. Ama scrumun yapısal çerçevesini yönetici belirler. Ek olarak da kaynaklar (Ressourcen) oluşturur (yer, alet vs.).

Rol dağılımında takım kendi kendini organize eder. Ne Scrum ustası ne de ürün sahibinin takım içinde kimin neyi ne zaman kiminle yapacaklarına dair bir yaptırımı olmaz.

Scrum'da klasik "Proje Yöneticisi'nin olmayışı, özellikle deneyimsiz bir Scrum ekibinde, Scrum ustası ya da ürün sahibinin (Product Owner) bu rolü üstlenmesi tehlike yaratır ve takımın Özerklik statüsüne zarar vererek, Scrumda sapmalara yol açar. Bu tehlikeyi azaltmanın yolu Scrum-ustası ve ürün sahibinin bir Scrum-Expert'inden yardım almasıyla sağlanabilir.

Bu toplantıda ürün sahibi kendi yazılım takımına ürün içeriğinde (Product Backlog) kararlaştırılan kullanıcı hikayelerini (User Stories) öncelik sırasına göre belirtir ve gereksinimler takım tarafından netleştirilip yazılı olarak kaydedilir. Kullanıcı da işlevsellik konusunda önemli bilgiler verebilir. Bunun dışında ürün sahibi ve takım sprint içinde olması gereken işlevler ve kriterler üzerinde anlaşırlar (bkz. Definition of Done).

Sprint'in kabul şartları kabul kriterleri (test, işlev, performans) ile etkileşimlidir. Bu tarz kararlar sprint sonucunda net şekilde belirlenir ve belirtilen fonksiyonların gerçekten içerdiklerine bakılır ve incelenir.

Genellikle küçük gruplar oluşturulup yapı, test, açık gibi konulara açıklık verilir. Burada beklenen sonuç görevlerin bir günlük süreyi aşmayacak şekilde bitirilmesini kapsar.

Görevler belirlenen kullanıcı hikâyelerinden hareketle duvara ya da beyaz tahtaya (Taskboard) asılır bu sayede hangisinin işlemde ya da sırada olduğu bilinir.

Her iş günü başlamadan evvel 15 dakikalık bilgi paylaşımı için günlük Scrum toplantısı yapılır. Bu görüşmede herhangi bir problem değerlendirilmez, yalnızca 3 tema işlenir: dün ne yaptım, bugün ne yapacağım, beni ne engelliyor. Eger belirtilen görev bir günde bitmesi mümkün değil ise, görev parçalanıp takıma dağıtılır.

Eger 15 dakıka içinde bazı sorular cevap bulamadığı durumlarda Scrum ustası not alıp bir sonraki toplantıya taşır ya da kendisi çözüm üretir.

Eğer teslim edilen işlevde eksiklik (test olmamış ise) var ise o kullanıcı hikâyesi tekrardan, ürün sahibi tarafından ürün içeriğine (Product Backlog) gönderilir ve öncelik sırası verilir.

Değerlendirmeye kullanıcının (User) katılımı da işlevin testi, ürün tasarımı ve kullanıcı bakışı açısından çok önemlidir. Kullanıcı Hıkayelerin de bir eksiklik var ise Scrum ustası tarafından not alınıp, ürün sahibi tarafından ürün içeriğine aktarılır.

Geçmişe bakış toplantıları, Sprint Değerlendirme toplantılarından sonra ve Sprint Planlama toplantılarından önce yapılırlar ve geçmiş sprint'teki tecrübeler masaya yatırılarak iyileştirmeler belirlenir. Scrum yönteminin en önemli özelliklerinden birisi bu süreçte suçlu/suçsuz eleştirilerinin yapılmamasıdır.

Sprint'de ürün geliştirilir. Yukarıda belirttilen her 2 Sprint planlama, her Sprint başlangıcında yer alır. Planlamada belirtilen ürün islevleri, Sprint'in sonunda teslim edilir.

Dışarıdan gelebilecek ekstra görev ya da taleplerden (takım elemanını ilgilendirse bile) ve takımı hedeften şaşırtıcı, her türlü engelin kaldırılmasında Scrum ustası sorumludur.

Geliştirme ekipleri içinde olası problemler: kurallara uyulmaması ya da görev in tamamlanmaması gibi durumlarda Scrum-ustası müdahale etmelidir. Talimat verme şeklinde değil anlaşma ve sonuçları kapsayan öneri ve hatırlatmalarda bulunmalıdır.

Sprint'in uygulama zamanı her zaman ayni olmalı ve uzatılmamalıdır. Bir Sprint en az bir hafta ve en fazla 4 hafta sürmelidir. Eğer hedeflenen sonuca Scrum sürecinde erişim mümkün değilse örneğin takım içerisinde çelişkilerin olması ya da taleplerin yanlış anlaşılması durumunda takım ya da ürün sahibi tarafından durdurulabilir.

Ürün İçeriği (Product Backlog) taleplerin oluşturulması ve yönetilmesi için merkezi belgedir ve teslim edilecek işlevsel elementler yönetilir. Toparlanan kullanıcı hikâyeleri ürün sahibi tarafından önceliklerine göre düzenlenir ve gerçekleştirilme zamanı takımın yardımı ile tahmin edilir.

Değişim taleplerinin alındığı tek yerdir ve ekleme, çıkarma, öncelikler gibi işlemler ürün sahibi tarafından yapılır. Ürün içeriği hiçbir zaman eksiksiz değildir ve böyle bir iddiasi da olmaz, tanımlanmış, iyi anlaşılmış gereksinimleri içerir, öncelikler ise ekonomik fayda, risk gibi faktörlerle değerlendirilip uygulanır.

Yazılım takımı elemanları günlük Scrum'da önceki gün hangi görev üzerinde çalıştığını ve bitip bitmediği hakkında bilgi verir. Bir günde bitmeyen görevler ise kırmızı bir nokta ile işaretlenir. Böylelikle engeller kolayca tespit edilir.

Bir Sprint yanik grafigi, x-ekseninde günlük zamanı, y-ekseninde bitirilmemiş görevleri gösterir. Bu grafik, Sprint'in belirtilen zaman birimi içinde daha iyi tahmin edilmesini sağlar.

Tüm projeyi göstermek için devir (Release)-iş bitim-grafiği kullanılır. Bu durumda y-eksenine bütün ürün içeriğinde belirlenen bitmemis kullanıcı hikâyeleri ve hikâye noktalarının toplanmış sekli gösterilir. Böylelikle proje bitimine kadar kaç tane teslimat yapılacağı anlaşılır.

Engel İçeriği (belirlenen tüm engeller) Scrum ustası tarafından, kısa bir problem tanımı ve tarih etiketiyle oluşturulur. Ek olarak günlük Scrum sonunda, Scrum ustası karşılaşılan engelleri ekler.

Bitti tanımı, bir kullanıcı hikâyesinin uygulanmasına ait ve yazılıma nüfus eden etkinliklerin kontrol listesidir. Ek belgeler olarak: yorum yazmak, birim testleri ve tasarım belgeleri.

Scrum ilk günden itibaren ürün geliştirmesinde olması gerekendeki sapmaları gösterir: hızlı, iyi, uygun fiyatlı ya da yüksek kalitede olması takımın kazandığı deneyimlere bağlıdır.

Geliştirme takımı içindeki önceki konumlarından vazgeçmek istemeyen üyelerin olması çelişkilere yol açabileceğinden hareketle iç disiplinin bilince çıkarılması, görevlerin dış destek olmadan yapılması için önemlidir.

Scrum'da proje ekibi sprint'deki tüm görevler üzerinde birlikte çalışırlar, böylelikle testci, yazılımcı, tasarımcı uyumu takıma yansır. Ancak deneyimli bir takım dezavantajları telafi edebilir.

Scrum uyglanmadan önce yeteri kadar ürün içeriği(Product Backlog) mevcut olmalı ve hangi teknolojik bir çatının kullanılacağıda kararlaştırılmalı ve uygulanmalıdır. Müşteriye verilen birinci fonksiyonalite olayın ciddiyetini ifade edeceğinden önemlidir.

Scrum takımı 5-8 kişiden oluşturulduğundan büyük projelerde aynı zamanda birden fazla Scrum takımı (katman) uluşturulur ve Sprint aynı anda başlar ve sonuçlar Sprint değerlendirme toplantısında sunulur.

Takım kordinasyonunu sağlamak için, her takım haftada 1/2 toplantı yapar (Scrum of Scrums), Scrum kurucularında Jeff Sutherland bir Scrum projesinde 800 kişinin çalışabileceğini belirtir.

Scrum temelde yazılım geliştirme yönetim olarak görülür ancak diğer metodlarla da basit kombine yapılabilir, bu XP (Extreme Programming) metodu ile denendi ve birbirlerine iyi uyum gösterdiği görüldü. XP@Scrum'ı Ken Schwaber ve Martin Fowler Trans Canada Pipeline Ltd. başarıyla uygulamıştır.