Değişen dünyada ticaret bir yarış halini almıştır. Her geçen gün hızlanan rekabette günlerin önemi giderek artmaktadır. Bu durumda firmalar ürünlerini en hızlı şekilde ellerinde görmek istemektedir. Bu süreç olabildiğince hızlı olmalı fakat süreci yönetirken meydana gelen değişiklikler istenen üründe yoksa ne olacak? Tüm çalışma boşa mı gitmiş olacak? En baştan yeniden mi başlanacak?
Ticarette proje yönetimi her zaman başarının anahtarı olmuştur çünkü diğer firmalardan farklılaşmanız yürüttüğünüz süreçte gösterdiğiniz başarıya bağlıdır. Başarı süreçlerin sonucu ise müşterinin ihtiyaçlarını tam anlamıyla karşılayan ürünleri zamanında teslim etmektir. Başarının anahtarı olarak görülen bir olgu üzerinde birçok çalışma yapılması hiç şüphesiz ki beklenen bir gerçektir. Firmalar kendilerini başarıya götürecek proje yönetimini bulabilmek ister. Günümüze kadar birçok yöntem arasından en kabul göreni “Şelale Yöntemi” ( Waterfall Method ) olmuştur. Ancak rekabetin artmasının doğal sonucu olan hızlı istek değişiklikleri, eski yöntemlerde meydana gelen gecikmeler, bütçe aşımları ve başarısız sonuçlar firmaları “Çevik Proje Yönetimine” (Agile Project Management) yöneltmiştir. Çevik bir proje yönetim biçimi en kısa sürede değerli çıktı üretmeye odaklanır. Çevik proje yönetimi çok kapsamlı olmayan ve belirsizliğin çok fazla olduğu, ihtiyaçların tam olarak belirlenemediği projeler için kullanışlı bir yöntemdir. Çevik proje yönetiminin en yaygın kullanım alanı yazılım geliştirme projeleridir. Proje boyunca müşteri ile proje takımı iletişim halindedir. Çevik proje yönetimi süreçten ziyade bireylerin daha etkileşimli olmalarına, kapsamlı dökümantasyonlardan ziyade çalışan yazılıma, sözleşme pazarlığından ziyade müşteri ile işbirliğine, bir plana bağlı kalmaktan ziyade değişime karşılık vermeye dayanır. Böylece değişen gereksinimler projenin son aşamasında bile kabul edilebilir olur, daha kısa süreli bildirimler ile hata payı azaltılır ve çalışan yazılım müşteriye sunulur, iş sahibi ve yazılımcılar süreç boyunca birlikte çalıştığı için faydalı bilgi alışverişi sağlandı.
Çevik proje yönetiminin uygulamalarında biride “Scrum” Tekniğidir. Scrum, ilk bakışta çok basit kuralları olan bir yönetimsel modeldir. Gereksinimleri açıkça belirli olmayan, değişime açık, karmaşık yazılım projelerinin yönetimi için uygulanmaktadır. Scrum, detaylı bir şekilde projede izlenmesi gereken adımları belirtmemekte, onun yerine basit ama önemli birkaç olmazsa olmaz kuralıyla çevik bir yönetim sunmaktadır. Scrum; 15 yıl önce yazılım endüstrisinde daha hızlı, daha güvenilir, daha etkili projeler oluşturmak için Ken Schwaber ile Jeff Sutherland tarafından geliştirilen bir yöntemdir. Scrum, Ragbi (Rugby) oyununda 8 kişiden oluşan bir takım anlamına gelmektedir. Bu takımda her bir birey diğer bireyle topu alanda hareket ettirmek için birlikte hareket eder. Sıkı bir şekilde çalışan takımlar, rolü iyice tanımlanmış olan takım elemanıyla bütünleşmiş (birleşik) birimler ve tek bir amaca odaklanmış bütün bir takım, bu oyunun en önemli özelliklerindendir.
İlk scrum uygulaması 6 aylık bir proje birer aylık sprint adı verilen 6 döneme bölünmüştür. Yarım gün süren ilk scrum toplantısında ürün gereksinim listesi (product backlog) oluşturulmuş ve sadece ilk koşunun detaylı planlaması yapılmış, diğer koşular ise kabaca tanımlanmıştır. Daha sonra her gün sabah 30 dakikalık bir scrum toplantısı yapılmış ve üyeler
. “Dün ne yaptın?”,
. “Bugün neler yapacaksın?” ve
. “Önünde ne gibi engeller/zorluklar var?”
sorularına cevap vererek birbirlerini bilgilendirmişlerdir. Ayrıca ekip üyeleri ortaya çıkan problemlere çözüm önerileri sunarak birbirlerini desteklemiş ve o günkü işlerini kolaylaştırmışlardır. Her sprint başında oluşturulan koşu gereksinim listesindeki işler öncelik sıralamasına alınarak gerçekleştirilmişlerdir. Bir sprint içinde her cuma günü ara ürün prototipi müşterilere sunulmuştur. Müşteriler, bu sunumlarda yeni gereksinimlerin farkına varmanın yanı sıra önemli yazılım hataları da yakalamışlardır. İzleyen haftada bu hataların düzeltilmesi ve yeni gereksinimlerin gerçekleştirilmesine başlanmıştır. Her sprint sonunda ilgili şirket yöneticisine de demo yapılarak ürünü kullanması sağlanmıştır. Yöneticiden gelen geri bildirimlerin değerlendirilmesi ve ürüne entegre edilmesi ile o sprint başarı ile kapatılmıştır. Tüm sprintler bu şekilde tamamlanarak 6 ay sonunda planlanandan daha çok işleve sahip ürün gecikme olmadan müşteriye teslim edilecek hale getirilmiştir.
Eski Yöntemler ve Scrum Arasındaki Farklar
Gartner Institute’un bilgisayar Teknolojileri (BT) sektörü araştırmasına göre BT projelerinin %74’ünün başarısız olduğu ya da maliyet/zaman hedeflerini aştığı tespit edilmiştir. BT projelerinin %51’i bütçesini %200 oranında aşmakta ve hedeflenen özelliklerin %75’ini karşılayabilmektedir. Yine Gartner Group’un (Technowledge SM 99 Presentation) yapmış olduğu bir araştırmaya göre BT projelerinin %70’i beklenen faydayı sağlayamamaktadır.
Üstte Chaos Report 2012’de, geleneksel (waterfall, predictive) yöntemlerle, 90’larda geliştirilmeye başlanan çevik (agile, scrum) yöntemler arasında bir başarı karşılaştırması yer almaktadır. Çevik yöntemlerle ilerleyen yazılım projelerindeki başarı oranı %42 olarak gerçekleşirken bu oran geleneksel yöntemlerde (waterfall) %14’te kalmıştır.
Scrum Süreci
- Proje sorumlusu (Project Owner) geliştirilmesi gereken tüm özellik ve fonksiyonları öncelik sıralarına göre toplayarak ürün gerikaydı (Product Backlog) hazırlar.
- Takım belirlenir ve “Sprint Planning” denilen en fazla 4 hafta sürecek olan küçük döngülerle (Sprint) işe başlanır. Her döngü için ürün gerikaydından önemli gereksinimler seçilerek sprint gerikaydı (Sprint Backlog) oluşturulur ve sprint boyunca bu gereksinimler geliştirilir.
- Takım bu “Sprint” süresince her gün Scrum Master liderliğinde bir araya gelir ve en fazla 15 dakika içerisinde her takım üyesi kendi ilerlemesini kısaca belirtir. Her gün yapılan ve 15 dk’yı aşmayan bu toplantılara Daily Scrum Meeting denir. Sprint süresince Burndown Chart denilen kalan gereksinimler/geçen zaman grafiği güncellenir.
- Sprint bittiği zaman bir “Sprint Review” raporu çıkarılır ve sprint süresince ortaya çıkan sorunlar ortadan kaldırılarak bir sonraki sprint rahatlatılmış olur.
- Sprint içerisinde biten özellik ve fonksiyonlar müşteri veya müşteri temsilcisine gösterilebilir.
- Yeni bir sprint için tekrar gereksinimler seçilir ve tekrar sprint hayat döngüsü başlar.
Scrum’da müşterinin üründen beklentileri karşılaması ilk önceliktir. Yukarda anlatılan süreç proje tamamlanana kadar sürekli uygulanır ve her süreç sonunda kaliteli ürün teslimatıyla müşteri memnuniyetini sağlanır. Müşteri de bu sürecin içinde aktif olarak rol alarak proje gelişimini takip eder. Düzenli aralıklarla ekipler kendi yöntemlerini gözden geçirerek verimliliği arttırmak için gerekli iyileştirmeleri yaparlar.
Kavramlar
1)Product Backlog; Proje için gerekli olan gereksinimler listesidir. Proje sonunda “Ne üretilmek isteniyor?” sorusuna cevap aranır. Product owner tarafından müşteriden gereksinimler alınır, öncelik sırasına göre sıralanır. Product owner, değişen ihtiyaçlara göre product backlog’a ekleme veya çıkarma yapabilir. Böylece değişim, projenin her aşamasında projeye kolayca entegre edilebilir olur. Ekip üyeleri iş listesindeki görevleri gerçekten yapıp yapamayacağını görmelidir. Görevleri tamamlamak için yeterli bilgi ve zaman mevcut mu? Görevleri tahmin ederken saat cinsinden tahmin etmek bizi yanıltabilir. Göreceli olarak tahmin etmemiz daha sağlıklı olacaktır. Fibonacci (1,2,3,5,8,13,…) serisini kullanabiliriz. Örneğin; ekip üyelerinin elinde üzerinde Fibonacci dizindeki sayılar olan desteler vardır. Tahmin edilecek göreve göre herkes gerekli çaba miktarını düşünerek ortaya bir sayı atar. Herkes kartlarını açar ve sayıların ortalaması alarak zamanı belirleriz.
Bu toplantıda sorulması gereken sorular;
- En büyük iş etkisi olan
- Müşteri için en önemli olan
- En fazla para kazandıracak olan
- Yapılması en kolay olan iş ne ?
2)Product Backlog Item; Product backlog içindeki her bir gereksinime verilen isimdir.
3)Sprint(Koşma); Proje sprint denilen küçük kısımlara ayrılır. Scrum içerisindeki tüm aktiviteler sprint içerisinde gerçekleşir.1–2 haftalık süreçlerdir.
4)Sprint Backlog; Geliştirme takımı tarafından product backlog itemlar öncelik sırasına göre sprint içerisine alınırlar. Bir sprint boyunca yapılacak itemların listesini oluşturur. İşlerin detaylı olarak zaman çizelgesi çıkarılır.
5)Scrum board; Bir sprint içerisinde yapılacak olan maddeler burada yönetilir. Yapılacak olan tasklar “TO DO” bölümüne alınır. Takım üyesi bu işe başladığında “IN PROGRESS” bölümüne getirilir. Bir iş, test için hazırsa “TO VERIFY” durumuna getirilir. İş, kontrol edildikten sonra “DONE” bölümüne getirilir. Scrum toplantılarında bu maddeler durumlarına göre yerleri değiştirilir.
6)Burndown Chart; Yatay ekseninde sprintin günlerini, dikey ekseninde sprintte kalan işi gösteren grafiktir. Scrum’un temel ilkelerinden olan şeffaflığı sağlar.
Roller
Pig Roller; Scrum sürecine dahil olanlar yani projede asıl işi yapan kişilerdir. Bunlar Scrum Master, Product Owner, Geliştirme Takımı’dır.
1) Product Owner; Geliştirme takımı ve müşteri arasındaki iletişimi sağlar. Projenin özelliklerini tanımlar. Projenin önceliklerine göre product backlogu oluşturur. Sprint’i iptal yetkisine sahiptir. Sprint neden iptal edilmek istenebilir? Hızla değişen ortamlarda bir sprinte alınan işlerin iş birimi için önemi kalmamış olabilir ya da sprinte alınan işlerden daha önemli işler ortaya çıkabilir. İş sahibi bunu görüp sprinti iptal etmek isteyebilir.
2) Scrum Master; Scrum kurallarını, teorilerini ve pratiklerini iyi bilir ve takımın bu kurallarını uygulamasından sorumlu kişidir. Takımın yöneticisi değildir. Takımı rahatsız eden, verimli çalışmalarını engelleyen durumları ortadan kaldırır.
3) Geliştirme Takımı; Bir Sprint’e alınan bütün işleri tamamlayacak özelliklere sahip kişilerdir. sprint backlogu oluştururlar. Kendi kendini yönetir. İşin verilmesini beklemezler, işi kendileri alır ve geliştirirler. Kişilerin tek bir görevi yoktur, çapraz görev dağılımı yaparlar, herkes her şeyi yapabilir konumdadır. Projenin geliştirilmesi ile ilgili sorumluluk geliştirme takımına aittir. Ekip üye sayısının etkisini hesaplamak için ekipte yer alan üye sayısı, kendinin bir eksiği ile çarpıp ikiye bölün. { [ ( n ) * ( n-1 ) ] / 2 }. Örneğin 5 kişilik ekibin 10 adet iletişim kanalı vardır. Bu sayı arttıkça diğerlerinin ne yaptığını bilme oranımız azalır ve bilmeye çalışırsak verimimiz azalır. Ekip büyüdükçe çarpık iletişim kanalı artar ve bu durum karmaşayı getirir. Yapılan deneyler ile insanların optimum şekilde başarılı olduğu çarpık iletişim kanalı sayısının 21 olduğu ortaya çıkmıştır. Yani bu durumda ekiplerimizin 7 kişi olması optimal noktadır.
Chicken Roller; Scrum’ın işleyişinde aktif olarak yer almayan kişilerdir. Müşteriler, satıcılar gibi.
Toplantılar
1) Sprint Planning; Product backlog ile belirtilen gereksinimler, bu toplantı ile geliştirme takımı tarafından küçük görevlere (task) ayrılır. Takımdaki her bir kişi kendi hızına göre bu taskleri kendilerine alır. Bu toplantıya product owner, geliştirme takımı ve scrum master katılır. Sprintler; her sprint sonunda product owner a sunulmak üzere yazılım geliştirmeyi hedefleyecek şekilde belirlenir.1–3 haftalık sprintler oluşturulur.
2) Daily Scrum; Her gün aynı yerde aynı saatte ayak üstü yapılan 15 dakikalık toplantılardır. Üyeler davet edilmeyi beklemezler. Bu toplantı gelecek 24 saati planlamak üzere yapılır. Takımdaki her üye dün ne yaptım,bugün ne yapacağım, işimi engelleyen herhangi bir sorun var mı sorularına cevap verir. Bu sayede herhangi bir sorunu var ise scrum master bu problemi ortadan kaldırır. Takım üyelerinden bu probleme yardımcı olabilecek biri var ise toplantı sonunda iletişime geçebilirler. Daily scrum her ne koşulda olursa olsun yapılır. Takımdaki birinin geç kalması veya gelmemesi toplantıyı etkilemez. Sadece takımdaki büyük çoğunluk yok ise toplantı yapılmaz.
3)Sprint Review; Her sprint sonunda yapılır. Yapılan sprint gözden geçirilir, ortaya çıkan ürün değerlendirilir. Amaç yazılımın ürün sahibinin gereksinimlerine uygun olarak geliştirildiğinden emin olmaktır. Eğer bir hata var ise farkedilir ve düzeltilir.
4)Sprint Retrospective; Sprint boyunca yapılan işlerin kalitesinin, doğruların ve yanlışların değerlendirildiği toplantıdır. Bu toplantı scrum takımının kendini geliştirebilmesi için bir fırsattır. “Neleri daha iyi yapabiliriz?”, “Nasıl daha iyi yapabiliriz?” sorularına cevap aranır. Bu aşamadan sonra bir sonraki sprint planning toplantısı gerçekleştirilerek yazdıklarımızın hepsi tekrardan yaşanır.
Faydaları
Bu metodolojinin avantajlarını müşteriye, kuruma ve yazılımcıya yönelik olmak üzere 3 kategoride net bir şekilde açıklayabiliriz:
1 ) Müşteri açısından avantajlar:
Önceki yöntemlerde müşteri sadece gereksinim belirleme ve son ürün aşamalarında sisteme entegre iken SCRUM metodolojisinde yazılım süreci boyunca müşteri-kurum ilişkisi söz konusudur. Başlangıç gereksinimler müşteri ile belirlenir. Tüm yazılım geliştirme süreci kısa süreli koşu (sprint) olarak adlandırılan dönemlere bölünür. Her koşu sonunda bir ara ürün oluşturulur ve müşteriye sunulur. Müşteri ara ürünü incelerken aklına yeni gereksinimler gelebilir, bazı gereksinimlerde değişiklik yapmanın uygun olduğunun farkına varabilir. Müşterinin öngördüğü değişiklikler bir sonraki koşuda yerine getirilir. Bu şekilde geliştirme takımının müşteri ihtiyaçlarına olabildiğince hızlı cevap vermesi sağlanmış olur. SCRUM’un en büyük kazanımı bu özelliğinden kaynaklanmaktadır. Geleneksel Şelale yönteminde ara kontroller yoktur ve son aşamada ortaya çıkan değişim istekleri çok büyük zorluk ve huzursuzluk çıkarır. Ürün teslimatının önemli ölçüde uzamasına sebep olur.
2) Kurumsal avantajlar:
Organizasyon sadece öncelik sırasına koyulmuş müşteri senaryolarına odaklanacağı için bu yöntem fazla yükü ve iş tekrarını önler. Geliştirme takımının verimliliğinin artması, metodolojinin müşteriye sağladığı faydalar ve müşteri memnuniyeti gibi faktörler müşterinin organizasyon hakkındaki olumlu düşünceler oluşturmasını ve organizasyona referans olmasını sağlar. Bunun sonucunda organizasyonun pazar potansiyeli de artar.
3)Yazılımcı açısından avantajlar:
SCRUM yazılımcıların ekipler halinde çalışmasını ve ekiplerin müşteri kanalı ile dış dünyaya açılmasını gerektirir. Şelale yöntemi gibi yöntemlerde bireysellik daha yoğun yaşanır. Yoğun bireysellik yazılımcıda enerji düşüklüğü, işten soğuma ve bu nedenlerle yavaşlama, konsantrasyon düşüklüğü gibi etkiler yaratır. İşin geliştirim süreci uzar ve yazılım hataları artar. Yazılım geliştirme süreci sırasında değil de süreç sonunda yazılımcıdan istenen değişiklikler yazılımcının gerilimini arttırarak isteksiz bir şekilde yazılımını değiştirmesine ve yazılım geliştirme sürecine başlamasına neden olur. Öte yandan SCRUM yazılımcıya dinamik ve sosyal bir ortam sunar. Yazılımcı, geliştirme süreci sırasında ekip arkadaşlarıyla sık sık bir araya geleceği için mutluluğu ve işine olan sevgisi artar. Ekip üyeleri arasında paylaşım ve katkılar yoğun olacağı için karşılaştığı sorunlar daha kısa sürede çözülür ve sorunun da ekip olarak sahiplenilmesi nedeniyle yazılımcının bireysel stresi düşük olur. Yazılım geliştirme süreci değişiklik isteklerini paralel olarak ele almayı gerektirdiği için de geri dönüş yükü minimuma indirgenir ve geri dönüş stresi de normal boyutta olur. Kısaca SCRUM yöntemi yazılım geliştiricinin ruh sağlığını koruyan ve kişisel gelişimine katkı sağlayan bir yöntemdir.
Scrum, değişen gereksinimlere hızlı uyum sağlamayı mümkün kılan, yazılım hatalarını azaltan, yazılım ekiplerinin entegrasyonuna zemin hazırlayan ve bu nedenlerden ötürü müşterilerin ve yazılımcıların memnuniyetini arttıran çevik bir yazılım geliştirme metodudur. Scrum, mümkün olduğunca basit tutulmalı ve gerçekleştirimiyle ilgili temel gereksinimleri içeren genel bir yöntem olarak tanıtılmalıdır. Scrum ile projenin %80 değerini oluşturan %20lik iş kısmına odaklanılır. Her kuruluş kendi scrum yöntemini kendi ihtiyaçlarına göre düzenlemelidir. Çünkü her ekibin kendi temposu ve ritmi vardır. Onları çok belirli kalıplara girmeleri için zorlamak felakete sebep olabilir. Kesin kurallar çeviklik kaybına ve verim düşmesine neden olur ve scrum adaptasyonunu da güçleştirir. Scrum, belirsizlik ve yaratıcılığı bir araya getirmektedir. Öğrenme süreci etrafında bir yapı kurmakta, ekiplerin hem ne yarattıklarını hem de en az o kadar önemli olan nasıl yarattıklarını birlikte değerlendirmelerine imkan tanır. Scrum ekiplerin gerçekte nasıl çalıştıkları bilgisini kullanır ve onlara kendilerini organize etme, süratle iş yapma ile hız ve kalitelerini geliştirme araçlarını sağlar.
Scrum, gerçek değeri mümkün olan en hızlı şekilde teslim etmek için vardır.
