Proje Geliştirme Süreçleri – Agile Scrum
Merhaba arkadaşlar
Proje geliştirme süreçleri ile alakalı bilgi almaya devam ediyoruz. Bildiğiniz gibi bir önce ki yazımda Waterfall metodunu türkçem yettikçe anlatmaya çalıştım. Bu yazımda ise farklı bir tür yeni bir trend herkesin öğrenmeye uygulamaya çalıştığı bir metot olan Agile Scrum metodundan yine türkçem yettiğince bahsetmeye çalışacağım 🙂
Agile türkçe meali Çevik olan bu metot aşamalı olarak projeleri geliştirmemizi sağlıyor ve bu sayede biraz esnek davranabilmemizi sağlıyor. Waterfall metodunda analiz kısmı bittikten sonra müşteriyle uzun süre görüşemediğimiz çok özlediğimiz doğrudur işte Agile yöntemi bu özleme son veriyor ve müşteri ile sürekli iletişim içinde bulunmamızı sağlıyor 😀 Yani kısacası Agile adı gibi projemize çeviklik kazandırıyor ve gerek hız gerek üretilen değerler açısından bize güzel faydalar sağlıyor. 🙂
Agile denen yöntemin içersinde de farklı frameworkler mevcut bunlardan biri Scrum diğeri XP dir. Windows XP değil ama 😀 meali Extreme Programming. 🙂
Bu metotlardan şimdilik Scrum dan bahsedeceğim XP için sonraki yazılardan birinde bahsedebilirim…
Scrum denilen şey itiş kakış anlamına gelen ama anlamı kadar karmaşa içinde yürümeyen bir yöntem. Bu yöntem içersinde bulunan bazı terimleri sizlere konu ile birlikte açıklamak isterim 🙂
Product Owner : İşi yaptırmak isteyen tarafta bulunan ve yazılımın tüm detayına hakim olan bize anlatabilecek arkadaştır.
Product Backlog : Yazılım için yapılmış analiz diyebiliriz. yazılımımız şöyle güzel olsun, böyle iyi olsun , hatta şöyle de güzel olsun içinden atlar kuşlar böcekler çıksın şeklinde olabilen ve ürünü yaptıracak olan Product Owner tarafından yazılmış belli formata sahip User Story‘ ler bütünüdür.
Herneyse bu PO (Petrol Ofisi değil Product Owner 😀 ) arkadaş bizlere fantazi dünyasının sınırlarını zorlayarak bütün bir product backlogu oluşturduktan sonra bu işleri en çok önemliden en az önemliye sıralar ve teslim eder. Product Backlog yaşayan bir liste olabilir yani sürekli madde eklenebilir silinebilir vs vs. Bu PO nun zevkine kalmış artık 🙂
User Story’ler INVEST diye kısa bir isimle adlandırılan kurallar dizisini içerirler.Invest şöyle sıralanır :
- Indipendent(Bağımsızlık):User Story kendi başına bir içeriğe sahip olmalıdır. Diğer user story’lere bağlı olmamalıdır.
- Negotiable(Tartışılabilir): User Story’ler, bir sprint içeriğine girene kadar her an değiştirilebilir.
- Valuable(Değer): bir user story son kullanıcı için bir değer ifade etmelidir.
- Estimable(Tahmin yürütülebilir): Bir user story’nin süresi tahmin edilebilmelidir.
- Sized appropriately(Makul boyut): User Story’ler plan, görev ve öncelik bakımından derecelendirilmesi ele alınabilmesi için çok kompleks yapıda olmamalıdır.
- Testable(Test edilebilirlik): User Story’ler test edilebilirliği mümkün kılmalıdır.
Sonrasında Scrum takımı bu product backloglar içersinde (burası önemli) her seferinde bir değer üretebilecek şekilde 2 veya 4 haftalık bir süre olan proje bitimine kadar tekrar eden ve Sprint adı verilen dönem içinde gerçekleştirilmek üzere görevleri alır sıralar kendi içinde dağıtır ve geliştirmeye başlar. Tüm bu işleri yöneten arkadaşa Scrum Master denir. Çok karizmatik bir ünvanı bulunan bu arkadaş takımın tüm yükünü omuzlarında taşır ,ihtiyaçları sağlar , engelleri kaldırır, gaz verir vs vs.
Bu takım Scrum kuralları gereği bazı seremoniler yapmak zorundadır. Mesela her sabah maksimum 15 dk süren “Ne yaptım?” “Ne yapacağım?” “Önümde engel varmı varsa neler?” sorularının kısaca cevaplandığı bir toplantı. Sonra Sprint başlamadan önce acaba hangi taskları alsakta yapsak müşteriye nasıl bir değer üretsek sorusunun tartışıldığı Sprint Review. Bir de takımın kendi içinde birbirini tebrik ,tahrik edebildiği yanlış varsa “ben nerde yanlış yaptım” şarkısının söylendiği güzel bir durum varsa ortamın şenlendiği garip bir o kadar ilk seferde adını söylemesi zor bir toplantı vardır ki oda Retrospective toplantısıdır. 🙂
Sprint başlar mutlu yazılımcılar kodlarını yazmaya başlarlar her gün birbirlerine mutluluk içinde neler yaptıklarını anlatırlar ve 2 veya 4 hafta dediğimiz sprint süresi sonunda müşteriye bir demo gösterirler bu elle tutulur gözle görülür müşterinin test etmesine olanak veren hatta ve hatta müşterinin “İyi olmuş hadi bunu Deploy edelim böylece” lafını söyletebilecek bir yazılım olmalıdır ki Scrum dediğimiz metot amacına ulaşabilsin 🙂
Scrum ı açıklayan çok güzel bir resim aşağıdaki gibidir 🙂
Peki bitti mi tabiki de bitmedi 🙂 birde son olarak bahsetmek istediğim küçük bir konu da Burn Down Chart.
Born-down chart İş sonu grafiği anlamına gelir ve Sprint sırasında takım üyeleri görevlerini yerine getirildikçe kalan iş ve yapılan iş arasındaki korelasyonu belirten bir grafik ortaya çıkar.İşte bu grafik takım üyelerine veya yöneticilerine fikir verir. Aynı zamanda takımın iş için istediği sürelerin yeterli olup olmadığı ve işin zamanında tamamlanıp tamamlanamadığı konusunda da fikir veren bir grafiktir. Adının burn down olması sanırım takımın işlerini zamanla eş değer şekilde bitirmeleri yakmaları eritmeleri vs. olabilir 🙂 Bu chart örneğinide yine aşağıdaki gibi görebilirsiniz.
Kısaca fikriniz olması açısından Agile ve Scrum ı açıkladım.
Umarım Yararlı Olur
Bilgiyle Kalın
M.Zeki OSMANCIK