ÇEVİK YAZILIM GELİŞTİRME : AGILE SCRUM METHODOLOGY

Bu yazımda Agile Yazılım geliştirme yöntemi ve Scrum Süreç Modeli’nden bahsedeceğim. Doğuş Teknoloji’de yaz stajımı yaparken tanıştığım bu kavramları staj süresince deneyimledim ve araştırdım. Gözlemlerimden ve bu sürecin öncesinde kullanılan Waterfall(Şelale) Modeli’nde zaman içerisinde projelerin daha büyük ve karmaşık bir hal alması, bununla beraber müşterinin büyük resmi göremeyip gereksinimlerini tam olarak ortaya koyamaması, teknolojinin çok hızlı değişmesi ile beraber gereksinimlerin çabuk değişmesi ve bunu projelere entegre edilemeyişi gibi problemlerden dolayı çoğu proje başarısızlık ile sonuçlanmaya başladı. Böylece proje sürecinin yönetilmesi konusu önemli bir konu oldu ve “Çevik (Agile) Yazılım Geliştirme Manifestosu” ortaya çıktı. Agile, belirsiz bir ortamda dahi başarılı olabilmek için değişime karşılık verebilme ve geliştirme yapabilme esnekliği, kapasitesi ve yeteneğidir.

Agile,

· Değişime hızlı karşılık verebilmeyi

· Kendi kendisine organize olabilen ve çapraz fonksiyonlu takımlar oluşturabilmeyi

· Projelerin bir bütün olarak bitmesini beklemek yerine projeleri değer üreten ve test edilebilir parçalar halinde pazara çıkmayı

· Teslim edilen her proje parçasından kaliteden ödün vermemeyi

· Müşteri için değer üretmeye odaklanmayı

· Çalışanların mutluluğunu arttırmayı

· Sürekli gelişen ve tüm bunları bir yaklaşım ve hareket biçimi olarak benimsemiş bir kültür oluşturmayı

· İletişimin arttırılmasını ve şeffaflığı

temel alan bir yaklaşım biçimidir. Çeviklik ancak pratikle kazanılabilen bir beceri, yaklaşım ve kültür olarak ifade edilebilir.

Agile yazılım geliştirme, Agile Manifesto’da vurgulanan değer ve prensipleri baz alarak bir dizi metot ve uygulamayı altında toplayan bir şemsiyedir.

Şimdi de biraz Scrum Süreçlerinden konuşalım.Öncelikle Scrum’ı Scrum yapan 5 temel değerinden bahsedeyim.

OPENNESS(Açıklık) : Scrum’ı destekleyen “Şeffaflık” ile doğrudan ilişkilidir. Açıklık, takım üyelerini birbirlerine karşı açık ve dürüst olmasını sağlar. Daily Scrum, takımın fiziksel olarak haftanın her günü aynı yerde ve aynı saatte yüz yüze gelerek tartışma imkanı sunar.

FOCUS(Odak) : Scrum, ürünü çabuk ve israfı en aza indirerek gereken çalışma yöntemlerini keşfetmeye yönlendirir. Bir ürünü bu özellikleri sağlayarak geliştirebilmenin aynı zamanda belirsizlik ve karmaşıklık ile baş edebilmenin en önemli koşulu ise odaklanmaktır.

COMMITMENT(Taahhüt) : Genellikle tüm kapsamın teslim edileceğinin taahhüdünü vermek gibi düşünülür. Oysaki karmaşık ve önceden tahmin edilemeyen yazılım geliştirme dünyasında, tüm kapsam üzerinden yapılan bir taahhüt sağlıklı olmayacaktır. Burada düşünülmesi ve benimsenmesi gereken konu, scrum ekibinin sprint hedefine yani Sprint Backlog’a dahil ettiklerini teslim etmeyi taahhüt etmesidir.

COURAGE(Cesaret) : Takıma genellikle işin hızlı çıkması için baskılar yapılmaktadır. Bu baskılar neticesinde teslim edilen çıktı kalitesiz ve karışık bir yazılıma yol açmaktadır. Her yazılım kaliteli ve teknik borçlarını azaltılarak geliştirilmelidir.Yazılımı geliştiren takım bu konuda cesaretini gösterip, “hayır” demeyi ve yazılımı taahhüt ettiği gibi kaliteli teslim etmeliyi kendine görev olarak bilmelidir.

RESPECT(Saygı) : Scrum’ın başarılı uygulanabilmesi için tüm scrum ekibi birbirlerine saygı göstermelidir. Takım içindeki üyelerin kişilik ve karakterleri farklı olabilir. Takım üyelerinin bu farklılığa uyum ve saygı göstermesi beklenir.

SCRUM’DA YER ALAN ROLLER

1) Product owner (ürün sahibi), bazı durumlarda müşterinin kendisinin, bazı durumlardaysa müşterinin isteklerini aktaran kişidir. Ürün olarak ne istediğini, üründen ne beklediğini ve amaçlarını yazılım ekibine aktarır. Product Backlog’unun güncel olması ve önceliklendirilmesinden sorumludur.

2) Scrum master, Scrum sürecinin yönetilmesinden, takıma koçluk yapmaktan ve takımın motivasyonunu yüksek tutmaktan sorumludur.

3) Development team (geliştirme ekibi), bir bütün olarak uygulamanın teslimi ve kalitesinden sorumludur. Ekibin üyeleri farklı becerilere, uzmanlıklara ve deneyime sahip olabilir ancak ekibin içinde unvanlar yer almaz. Herkes uygulamanın oluşturulmasına katkıda bulunur.

Özetleyecek olursak, Product owner, yani ürün sahibi bitirmesi gereken işleri tanımlamaktan sorumludur. Developer Team, yani geliştirme ekibi bu işlerin nasıl tamamlayacağından ve tamamlamaktan sorumludur. Scrum master ise tüm sürecin kurallara uygun ve sorunsuz bir şekilde işletilmesinden sorumludur. Ayrıca, bitmiş işin tanımının yapılması çok önemlidir. Bir iş “bitmiş” denildiğinde herkesin kafasında tek bir tanım yer almalıdır.

SCRUM SÜREÇLERİ

Sprint, projeye ve ekibe bağlı olarak 1 veya 4 haftalık süreçlere verilen isimdir. Scrum, birbirini takip eden Sprintlerden oluşmaktadır ve her bir Sprint sonunda müşteriye sunulabilecek bir iş çıkarılmalıdır. Sprint’in kaç haftadan oluşacağı ekibe ve projeye bağlıdır.

Product backlog, istenilen ve tamamlanması gereken işlerin listesidir. Burada işler önem sırasına göre sıralanır. İşler olabildiğince küçük parçalara bölünür, her iş parçası 1–3 iş günü uzunluğundadır. Product Backlog, User Storylerinden oluşur. Product owner, değişen ihtiyaçlara göre Product backlog’a ekleme veya çıkarma yapabilir.

Sprint backlog, bir Sprint boyunca bitecek işler kararlaştırıldıktan sonra, Sprint’in başlamasıyla birlikte yer almaya başlar. Tüm işler önceliklendirilmiştir ve Sprint, sonuna kadar bitmesi gereken işlerdir.

User story, yapılacak işin son kullanıcı açısından anlaşılır bir şekilde açıklamasıdır. User Story kullanıcı türünü, ne istediğini ve gerekçelerini tanımlar ve gereksinimin basitleştirilmiş bir açıklamasını oluşturmanıza yardımcı olur. User Storyleri belirli bir formatta yazılır.

“As a:<role> I want to: <function-description> So I can: <value-statement>”

User Storyleri kapsam ve uzunluklarına göre farklı kategorilere ayırabiliriz: Story, 1–2 iş uzunluğundaki iş parçalarıdır ve bir Sprint’ten uzun sürmeyen işler için kullanılır. Epic ise birçok Story’den oluşur. İşin kapsamı ve uzunluğu Story’e göre fazladır. Aynı amaca hizmet eden Storyler aynı Epic içerisinde yer alır. Bir epic’in tamamlanması birkaç Sprint sürebilir.

Sprint Planning (Planlama Toplantısı): Sprint başlamadan önce Product Owner, Sprint için bir hedef tanımlar ve hangi User Storylerinin tamamlanması gerektiğini belirler. Product Owner ile Development Team birlikte çalışarak, hangi işlerin gelecek Sprint’e alınacağına karar verir. Geliştirme Ekibinin kapasitesini aşması halinde hedefin birden fazla Sprint’e ayrıştırılabilir. Daha küçük parçalara ayrılması gereken işler varsa küçük parçalara ayrılır ve işler önceliklendirilerek bir sonraki Sprint hazır hale getirilir.

Daily Scrum Meeting (Günlük Sprint Toplantıları): Scrum takımı olarak günlük yapılan toplantılardır. Genellikle sabahları yapılır ve en fazla 15 dakika sürer. Herkesin katıldığı bu toplantıda, dün yapılan, bugün yapılacak işler ve yaşanılan problemler aktarılır. Burada amaç ekibin yüz yüze iletişim halinde bulunması, herkesin birbirine karşı sorumluluk hissetmesi ve ekip içi şeffaflığın sağlanmasıdır.

Sprint Review (Demo Toplantısı): Toplantıda geliştirme ekibi herkese bir Sprint boyunca neler yaptığını ve ortaya çıkan ürünü gösterir. Her Sprint sonrası gerçekleşen Sprint Review’de Development Team, Scrum Master ve Product Owner bulunur. Review sonrası müşteri gerekli geri bildirimleri verir ve değiştirilmesini veya geliştirilmesini istediği bir şey varsa belirtir. Amaç, ortaya çıkan ürünün ürün sahibinin gereksinimlerine uygun olarak geliştirildiğinden emin olmaktır.

Sprint Retrospective: Scrum takımının kendisini değerlendirmesi ve sürekli gelişimi devam ettirmek için Sprint sonunda gerçekleştirilen bir toplantıdır. “Neleri daha iyi yapabiliriz?”, “Nasıl daha iyi yapabiliriz?” gibi sorulara cevap aranır. Takım, kendisini değerlendirerek neleri doğru neleri yanlış yaptığı ve neleri daha iyi veya farklı yapabileceği üzerine konuşur ve iyileşmeler üzerine tartışır. Bu toplantılar, takımın kendisini bir sonraki Sprint’e daha iyi hazırlamasını sağlar.