21 Eylül 2014 Pazar

AGILE METODOLOJİSİ & SCRUM

AGILE (ÇEVİK) METODOLOJİ 

Agile Metodoloji (Çevik Metodoloji) yazılım sistemlerini etkili ve verimli bir şekilde modellemeye ve dokümantasyonunu yapmaya yönelik pratiğe dayalı yöntemlere denir. 
Diğer sektörlerde ki yaklaşımların bir devamı olarak 1970’li yıllardan itibaren yazılım sektöründe uygulanmaya başlanmıştır. Aşırı kuralcı klasik yazılım süreç modellerine tepki olarak ortaya çıkan Agile Manifestosu öncesinde yazılımlar daha yüksek maliyetli ve daha yavaş geliştirilmekteydi. 
Yazılım geliştirme sürecini hızlandırmak, daha etkin kullanmak ve gerektiğinde dokümante etmek amacıyla ortaya çıkan, Dünyada birçok yazılım firmasının farklı projelerinde benimsediği bu metodun kullanımı 1990’larda hız kazanmıştır. 


2001 yılında yazılım dünyasının önde gelen isimlerinden Kent Beck ve 16 arkadaşı “Çevik Yazılım Geliştirme Manifestosu” ve “Çevik Yazılımın Prensipleri” ni yayınlamışlar, bu oluşumu ve gelişimini desteklemek için “Agile Alliance” adıyla kar amacı gütmeyen bir organizasyon kurmuşlardır. 
Manifesto, nasıl daha iyi bir yazılım geliştirdiklerini ve bunu yapmak isteyenlere yol gösterecek 4 maddeden oluşmaktadır. 


Agile(Çevik) Manifestosu 
1. Bireyler ve etkileşimi, süreç ve araca tercih etmek. 
2. Çalışan bir yazılımı, detaylı belgelendirmeye tercih etmek. 
3. Müşteri ile işbirliğini, sözleşmedeki kesin kurallara tercih etmek. 
4. Değişikliklere uyum sağlayabilmeyi, belirli bir plana tercih etmek. 
  
(Soldakilerin sağdakilere göre üstünlüğü kabul edilir. Fakat bu sağdaki unsurların önemsiz olduğu anlamına gelmemelidir) 
  
AGILE(ÇEVİK) Prensipleri

İlk önceliğimiz kaliteli yazılımı müşteriye teslim edebilmektir. Bu projenin ilk aşamalarından itibaren sürekli teslimlerle yapılır ve müşterinin yazılımı çok önceden kullanmaya başlayarak deger sağlamasına olanak sağlanır. Günümüzde çevik süreçlere artan ilginin başlıca nedenlerden biri , yapılan yatırımların hızlı geri dönüşünün olmasıdır. 
Değişiklikler projenin ilerki aşamalarında dahi olsa kabul edilir. Amaç müşterinin ihtiyaçlarını karşılayan,onlara yarar sağlayacak , gerçek değer katacak yazılım üretmektir ve ihtiyaçlarda meydana gelen değişiklikler projenin sonraki aşamalarında dahi yazılıma aksettirilmelidir. Test, güdümlü tasarım, kapsamlı otomatik testler, sürekli entegrasyon, basit tasarım gibi pratikler sayesinde değişikliklerin getireceği maliyetler minimuma indirilir ve süreç değişikliklere çabuk adapte hale getirilir. 
Çok kısa aralıklarla yazılım teslimleri yapılır. Bu aralıklar tipik olarak 2-4 hafta arasıdır. Bu sayede sürekli geri beslenim (feedback) sağlanır ve müşterinin tam istediği şekilde yazılım evrimleşerek gelişir. 
Alan uzmanları , yazılımcılar, testçiler günlük olarak birlikte çalışırlar. Farklı roller arasında duvarlar örülmez. Rol bazlı ekipler yerine yazılım özelliklerine(features) göre ekipler oluşturulur.  Analist, yazılım geliştirici vb. aynı ekibin içinde çalışır ve sürekli iletişim halindedir. 
Projeler, "motive birey" odaklı kurulur ve ekip üyelerine kendileri ile ilgili alacakları kararlar konusunda güvenilir. Ekip kendi kendine organize olacak yetkiye sahiptir. 
Yüzyüze iletişim diğer her türlü iletişim yönteminden önde tutulur. 
Projedeki gelişmenin tek ölçüsü o ana kadar geliştirilmiş özellikler ve çalısan yazılımdır. 
Çevik süreçler devam ettirilebilir bir hızı sağlamaya çalışır. Planlamaların sağlıklı olması için ekibin iş teslim hızının üzerinde çok oynanaması gerekir. Örneğin fazla mesailer gibi yöntemlerle ekibin hızını geçiçi olarak arttırmak tercih edilen yöntemlerden değildir. 
Teknik açıdan mükemmel , basit fakat sofistike çözümler oluşturulmasına özen gösterilir. 
Sadelik anlayışı akla gelen baştan savma çözümü uygulamak yerine, anlaşılması ve sonradan değiştirilmesi kolay , maliyeti en düşük ve o an ki gereksinimleri karşılayan çözümü kullanmaktır. 
En etkin çalışan ekipler kendilerini organize edebilen , bu konuda yetkin ekiplerdir. Ekip kendi çalışma yöntemlerini sorgulamakta ve gerekli değişiklikleri yapmakta özgürdür. 
Ekip kısa sürelerle toplanır, çalışma yöntemlerini gözden geçirir ve daha etkili çalışmak için geriye dönük (retrospective) toplantılar yaparak durumları gözden geçirir. 
  
AGILE Neden Ortaya Çıktı ? 
      Gartner Institute’un BT sektörü araştırmasına göre: BT projelerinin %74’ü başarısız ya da maliyet/zaman hedeflerini aşıyor. BT projelerinin %51’i bütçesini %200 oranında aşıyor ve hedeflenen özelliklerin %75’ini karşılayabiliyor. Standish grubun 2000 yılında gerçekleştirdiği bir araştırmaya (Chaos in the new Millenium 2000) göre yazılım projelerinin başarıya ulaşma oranı %28 olarak veriliyor. Diğerleri ya başarısız (%23) ya da zorlanmış (%49) projelerdir. Aynı araştırma yazılım projeleri özelinde de proje maliyetlerinin tahmin edilenin üzerinde olduğu veya zaman aşımı olduğu ya da niteliklerin istenilene tam uygun olmadığını gösteriyor. Gartner Group’un (Technowledge SM 99 Presentation) yapmış olduğu bir araştırmaya göre BT projelerinin %70’i beklenen faydayı sağlamıyor. 
     Gartner Institute’un 2001 BT sektörü araştırmasına göre: Amerika’da her yıl başarısız BT projeleri için 75 milyar dolar harcanıyordu. Şuanki rakamları bir düşünün... 
  
ÇEVİK METODOLOJİLER 
1.Sınırsal Programlama (Extreme Programming-XP) 
2.Çevik Birleştirilmiş Süreç (AGILE Unified Process) 
3.Scrum 
4.Test Güdümlü Geliştirme (Test-Driven Development) 
5.Çevik Bilgi Metodu (AGILE Data Method) 
6.Özellik Güdümlü Geliştirme (Feature-Driven Programming), 
  
SCRUM 
•Rekabetçi piyasa koşulları nedeni ile şirketin karlılığının arttırılmasında sağladığı faydalar; yeniliklere /değişen teknolojilere ayak uydurmaktaki esneklikler, SCRUM metdodu waterfall metodlara karşı üstün kılar. 
Scrum karmaşık ve belirsiz gereksinimlerin olduğu projeler için daha anlamlıdır. 
Scrumda tahmin edilebilirlik optimize edilir, riskler revize edilerek amaca doğru katmadeğerli olarak ilerlenir. 
•Yüz yüze iletişim olduğundan ekip içerisinde kaliteli bilgi akışı sağlanır. 
•Kapsam tamamlandıktan sonra projeye başlanmaz. Kapsam proje boyunca tamamlanmaya çalışılır. 
•Çoğu zaman, müşteriler büyük resmi göremediklerinden, isterlerinin tamamını projenin başında iletemezler.Maliyeti nedeni ile ertelenen müşteri talebi de, müşterinin istemediği şekilde prod’a çıkılması sonucu, müşteri memnuniyetsizliğine neden olur. 
Scrum metodta müşteriden gelecek CR’lar her bir SPRINT'te handle edilerek ilerlenir.Bu da müşteri memnuniyetinin arttırılması demektir. 
•İlk SPRINT'teki maddeler ilk aşamada bilinen ve çok iyi analaşılmış gereksinimlerdir.Kapsam dinamiktir. Ürün yaşam döngüsü boyunca güncellenir. 


SCRUM’IN BAŞARISI İÇİN; 
•Product owner sorumluluğunu alacak müşteri, konusuna hakim olmalı ve geliştirme ekibi ile işbirlikçi bir tutum sergilemelidir. 
•Kişiler hiyerarşik olarak değil, yetkinlikleri ile bir arada oldukları bilincinde olmalıdırlar. Takım üyeleri arasında ast üst ilişkisi olmamalıdır. 
•Her role tanımlanmış kişiler sorumluluklarını yerine getirmelidir. 
•Toplantıları düzenli olarak yapılmalıdır. 
•Hızlı şekilde, müşteri tarafından kullanılabilir çıktılar üretilmelidir. 
PRODUCT OWNER 
•Ürün kapsamının (product backlog)yönetiminden sorumludur. Product owner bir grup değil, bir kişidir. Product backlog'taki maddeler net şekilde ifade edilmelidir. 
•Maddeler önceliklerine göre sıralanmalıdır. 
•Product backlog'taki maddeler analistlerle birlikte hazırlansa da sorumluluk product owner’dadır. 
•Geliştirme ekibindeki kişiler product owner’ın yönlendirmesi ile hareket eder. 
•Product owner projenin çıktılarını onaylar. 
•SPRINT backlog'taki görevi 
–Görevin kimin sorumluluğunda olduğunu 
–O görevi tamamlamak için daha ne kadar efor gerektiğini belirtmektir. 
  
GELİŞTİRME TAKIMI 
•Her SPRINT'in sonunda ürün çıkaran ekiptir. 
İterasyon içinde üretilen tüm ürünlerden sorumludur. 
•Grubun içinde ünvanlar yoktur. 
•Konu bazlı uzmanlaşma olsa da , ürünle ilgili tüm sorumluluk bütün proje ekibine aittir. 
•Takım en az 3 enfazla 9 kişiden oluşmalıdır. 
  
SÜREÇ YÖNETİCİSİ (Scrum Master) 
•Sürecin anlaşılmasından ve kuralların doğru işletilmesinden sorumludur. 
•Geliştirme takımının önündeki engelleri aşmak adına, geliştirme takımına hizmet ederler. 
Backlog'taki maddelerin açık ve geliştirme ekibi tarafından anlaşılır olmasına yardımcı olurlar. 
•Geliştirme takımını eğitmeli ve onlara liderlik etmelidirler. 
•Dışardan gelebilecek ekstra görev ya da taleplerden (takim elemanını ilgilendirse bile) ve takımı hedeften şaşırtıcı, her türlü engelin kaldırılmasından Scrum master sorumludur. 
•Geliştirme ekipleri içinde olası problemlere (kurallara uyulmaması ya da görevin tamamlanmaması gibi durumlar) Scrum-ustası müdehale etmelidir. Müdahale; talimat verme şeklinde olmamalıdır.Anlaşma sağlamaya yönelik olmalı ve önerilerde bulunmak ya da aksayan işler için hatırlatmalarda bulunmak şeklinde olmalıdır. 


SPRINT 
Max 1 ay süresi olan, 1 ay sonunda ilgili iterasyonda çıkması planlanan ürünün geliştirildiği fazlardan her birine denir. 
•SPRINT kapsamındaki maddeler, SPRINT backlog'ta listelenir. 
SPRINT'ler biribirini izler. 
•Bir SPRINT'in ardından diğeri başlar. 
  
SCRUMDA TOPLANTILAR 
Scrumda 4 temel toplantı vardır: 
•Sprint Planlama Toplantısı: SPRINT süresince yapılacak işler planlanır.Scrum takımının katılımı ile gerçekleştirilir. 1 aylık SPRINT için ayrılacak SPRINT planlama toplantısı max. 8 saattir. Bir önceki SPRINT'teki ürün, önceki SPRINT'in performansı ve ilgili SPRINT'in kapasitesi görüşülür. SPRINT'te ne kadar işin yapılabileceğine geliştirme takımı karar verir. 
•Sprint Planlama Toplantısı 1:Product backlog'taki maddeler, netleştirilerek önceliklendirilir. Bu toplantıda “NE” sorusunun cevabı aranır. 
•Sprint Planlama Toplantısı 2: Bu toplantıda “NASIL” sorusunun cevabı aranır. Sprintin kapsamı ve gereksinimler bellidir ve nasıl yapılacağı konuşulur. Açık konular netleşltirilir. Bir günlük süreyi aşmayacak şekilde sonuçlandırılması beklenir. 



•Sprint Günlük Toplantısı: 15 dakika ile sınırlı bir aktivitedir ve ayakta gerçekleştirilir. Hangi işlerin yapıldığı, bir sonraki toplantıya kadar hangi işlerin tamamlanmasının planlandığı ve varsa planlanan işlerin önündeki engellerin neler olduğu görüşülür. (dün ne yaptım, yarın ne yapıcam, beni ne engelliyor) SPRINT süresince “burndown chart” denilen kalan gereksinimler/geçen zaman grafiği güncellenir. 
•Sprint Gözden Geçirme Toplantısı: SPRINT süresince neler yapıldığı konuşulur. 1 aylık SPRINT süresinde 4 saat zaman ayrılır. Amaç bir önceki SPRINT için geri bildirim almak ve işbirliğini arttırmaktır.Bu toplantının sonunda revize edilmiş ürün kapsamı çıkar. 
•Sprint Süreç İyileştirme Toplantısı:SPRINT gözden geçirme toplantısı ile SPRINT planlama toplantısı arasında yapılır. 1 aylık SPRINT'te max. 3 saat olarak gerçekleştirilir. İyi yapılanlar ve gelişeme açık yönler görüşülür. Eksik yönlerin düzeltilmesi için iyileştirme planları hazırlanır. Scrum takımı bir sonraki SPRINT'te iyileştirmeleri tamamlamış olmalıdır.  
Yeni bir SPRINT için tekrar gereksinimler seçilir ve tekrar Sprint Hayat Döngüsü başlar. 
  
  

2 yorum:

Adnan ÖNCEVARLIK dedi ki...

:) Scrum -> Kervan Yolda Düzülür. Biz binlerce yıldır uyguluyoruz :) Hehehehehe

Dubai Escort Girls dedi ki...

Dubai Escort, Dubai Escorts, Escort Dubai, Escorts Dubai,
Escort in Dubai, Escorts in Dubai, Dubai Escort Girls,
Escort Service Dubai, Dubai Escorts girl, Dubai Escort Directory,
Escort UAE, UAE Escorts, Escorts in UAE, Dubai Vip Escort

Yorum Gönder

Twitter Delicious Facebook Digg Stumbleupon Favorites More