Agile Method-Scrum

       Extreme method  için tarihsel gelişime baktık. Agile için bakmayalım mı? Bakalım tabi ki...
       2000 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. 
(Kent Beck-Mike Beedle-Arie van Bennekum-Alistair Cockburn-Ward CunninghamMartin Fowler-James Grenning-Jim Highsmith-Andrew HuntRon Jeffries-Jon Kern
Brian Marick-Robert C. Martin-Steve Mellor-Ken Schwaber-Jeff Sutherland- Dave Thomas)

AGILE MANİFESTOSU

1. Individuals and interactions over processes and tools

Bireyler ve etkileşimi, süreç ve araca tercih etmek.

2. Working software over comprehensive documentation

Çalışan bir yazılımı, detaylı belgelendirmeye tercih etmek.

3. Customer collaboration over contract negotiation

Müşteri ile işbirliğini, sözleşmedeki kesin kurallara tercih etmek.

4. Responding to change over following a plan

Değişikliklere uyum sağlayabilmeyi, belirli bir plana tercih etmek.

       Çevik Yazılım Metodu İlkeleri

              Müşteriye hızlı bir şekilde kullanılabilir çıktılar üretilmelidir.

              Esneklik vardır.

              Müşteri, yazılımcılar, test ekibi birlikte ve iletişim halinde çalışırlar.

 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 metodu waterfall metotlara 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 katma değ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, isteklerinin 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 metotta 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 anlaşılmış gereksinimlerdir.Kapsam dinamiktir. Ürün yaşam döngüsü boyunca güncellenir.

Extreme Programing(XP) Uygulama Pratikleri

On-site Customer(Ekipteki Müşteri)

Daha önce de dediğimiz gibi XP’de süreç müşteriye göre şekil alır ve onun istekleri doğrultusunda yazılım şekillenir. Bu yüzden müşterinin (genelde bir kişi tercih edilir; ama uyumlu ise birden fazla kişi de olabilir) ekipte olması önemlidir.

Planning Game(Oyun Planı)

XP iteratif (tekrarlanan, ardışık devam eden) ve incremental (değişen, marjinal) bir yazılım metodolojisidir, bu yüzden tam bir takım oyunu gerektirir, bu nedenle her bir sürüm için ekip bir arada planı geliştirir. Plan herhangi bir iş için kaçınılmazdır, aksi halde süreçleri kontrol etmek ve ortaya düzgün bir iş koymak mümkün değildir.

Short Releases(Kısa Sürümler)

XP temelde kısa sürede ortaya çalışan bir uygulama koymak ister, böylece hem müşteri istekleri doğru alınır, hem memnuniyeti sağlanır hem de ekibi canlı tutmayı sağlar. Uzun vadeli işler genelde sıkıcı olabileceği için kısa vadede ortaya çıkan ürün geliştiriciler için de şevk vericidir. Bu yüzden basitlik tercih edilir.

Stand-up Meeting(Ayakta Toplantı)

Bu tür toplantılar en fazla 15 dakika olacak şekilde ayarlanır. Temelde yapılmak istenen projenin durumu hakkında bilgi alışverişinde bulunmaktır.

Retrospective(Geriye Bakış)

Temel amaç yaşanan problemlerin analizini yapmaktır, böylece aynı hatanın gelecekte tekrar etmesinin önüne geçilmiş olur.

Metaphor(Mecaz)

Mecaz kullanmanın maksadı geliştirilecek yazılımın içeriği hakkında ekibin bir fikrinin oluşmasıdır. Örneğin e-ticaret uygulaması geliştirecek ekip için alış veriş sepeti bir metafor olarak kullanılabilir. Böylece metafor ekibe söylendiğinde herkesin kafasında e-ticaret sistemi yazacağı fikri kolaylıkla oluşacaktır.

Collective Ownership(Ortak Sorumluluk)

Klasik modelde programcılar genelde yalnız kendi yazdıkları kodlardan sorumludurlar, klasik yöntemle çalışan programcılar başkalarının kodları üzerinde oynamak istemezler. Oysaki XP’de tüm programcılar kodu sahiplenir, gerektiğinde değiştirir.

Continious Integration(Sürekli Entegrasyon)

Projeye eklenen yeni bölüm veya komponentler sisteme hemen entegre edilir ve test edilirler. Bu hem diğer programcıların da gelişimi görebilmesini sağlar hem de daha sonra yazılımın parçalarını entegre etmek için ekstra zaman kaybı yapılmamış olur.

Coding Standards(Kod Yazma Standartları)

Birden fazla yazılım geliştiricinin yer aldığı uygulamalarda olmazsa olmaz bir durumdur. Ortaya kaliteli ve stabil çalışan bir ürün çıkarılabilmesi için değişken isimlendirmeden, kullanılacak alt yordam, fonksiyon formatına kadar belirlenir. Böylece her programcı bir başkasının koduna müdahale ettiğinde kodu okumakta zorlanmaz ve gerekli değişiklikleri yapabilir.

Sustainable Pace(Kalıcı Tempo)

XP, haftalık 40 saat çalışma planı sunar. Yorgun, uykusuz bir programcı verimli olamayacağı için fazla çalıştırılmasına tamamen karşı çıkar ve günlük 8 saat olmak üzere haftada 40 saat çalışmaya sadık kalır. Böylece projede aksamalar kolay kolay olmaz.

Testing(Test Etmek)

XP testleri çok önemser ve muhakkak yapılması gerektiği üzerinde durur, hatta daha da ileri giderek önce gerekiyorsa test yazılımlarının kodu yazılır, sonra yazılım geliştirme aşamasına geçilir.

Simple Design(Basit Dizayn)

XP’de geliştirilen yazılım en basit hali ile geliştirilir, kompleks olmamasına özen gösterilir, böylece yeni geliştirmeler kolayca entegre edilebilir.

Refactoring(Yeniden Yapılandırma)

Yazılım tasarımı yapılırken yapılan bir hata bazen telafisi zor sorunlara yol açabilir, bunun için yazılan kod parçacığının yeniden yapılandırması gerekebilir.

Pair Programming(Eşli Programlama)

Temelde aynı bilgisayarda iki programcının çalışması tavsiye edilir. Bir programcı yazarken diğer programcı kodlama yapısına dair düşünür ve tavsiyelerde bulunur, sonra diğer programcı yazmaya başlar ve diğeri aynı görevi yerine getirir. Bu hem programcı yedekliliğini sağlar, hem de kod yazanların kalitesinin yükselmesini sağlar.

Extreme Programing(XP)

       Merhaba arkadaşlar bir önceki yazımda yazılım metotlarının tamamını anlatamamıştım. Bu yazıda Extreme Programing (XP) gelecek yazımda ise Agile Metottan bahsedeceğim. Hemen metodumuzu incelemeye geçelim.
       Öncelikle tarihsel bilgileri paylaşmak istedim sizinle. Extreme Programming (XP) metodu ilk defa 1999 yılında Kent Beck tarafından duyuruldu. Temelde XP metodu 1996 yılında Chrysler firmasındaki bir proje esnasında Kent Beck, Ron Jeffries ve Ward Cunningham tarafından geliştirildi.

Kent Beck

       Ne zaman kim tarafından çıkarıldığını öğrendik. Peki niye metot çıkartma gereksinimi duyuldu. Yazılım Mühendisliği metotlarının aşırı dokümantasyon içermesi ve zaman alıcı bir süreci beraberinde getirmesinden dolayı böyle bir metot ortaya atılmıştır.
       XP’nin ortaya çıkmasına neden olan eleştiriler şunlardır:

• ·         Çalışan program oldukça geç ortaya çıkıyor
• ·         Çalışan program geç çıktığı için hatalarında farkına çok geç varılıyor
• ·         Verimli değil
• ·         Esnek değil, yeni isteklere cevap verip ona uyum sağlayamıyor
• ·         Değişiklik geç ve oldukça zor yapılıyor

       XP 5 temel ilkeye sahiptir.

            1.Basitlik
                XP süreçlerinde değişime ayak uydurabilmek adına sürümler sadece ihtiyaca yönelik çıkartılırlar. Müşteri ile birlikte oluşturulan yazılım ihtiyacı temelde neyi kapsıyorsa yalnızca onlar yapılır, böylece boşa adım atılmamış olur, kayıplar sıfırlanır. Her bir sürüm bir diğeri ile entegre olacağı için karmaşık yapılardan özenle kaçınılmalıdır.

            2.İletişim

                XP ekibin iletişimini fazlasıyla önemser. Müşteri, yönetici, son kullanıcı, test uzmanı ve yazılım geliştiriciler ekibin bir parçasıdır. Ekip üyelerinin tecrübelerini ve öngörülerini paylaşması projenin başarısı için oldukça kilit konumdadır. Müşteri isteğini ortaya koyar, son kullanıcı bu durumda beklentilerini iletir, yazılım tasarım analistleri isteklerin belirginleşmesinde müşteriye destek olur ve yazılım geliştiriciler işin ne kadar zamanda biteceğini belirlerler.

             3.Geri Bildirim

                 XP’nin başarısının ardındaki en önemli adım geri bildirimdir. Bu da testler aracılığı ile yapılır.Yazılım geliştiriciler kendi yaptıkları kodları zaten test ederler; ama senaryolar içerisinde bazen beklenmedik sorunlar oluşabilir, bu sebeple bir test uzmanı tarafından senaryolar dahilinde yazılım test edilir ve eksik veya hatalı olan kısımlar iletilerek hemen değiştirilmesi sağlanır.

              4.Cesaret

                 Cesaret, yapılan işlerde gerekirse hemen değişiklik yapmayı simgeler. Bu klasik yöntemlerde pek tercih edilmeyen bir unsurdur, çünkü birçok şeyi baştan almak maliyetleri yükseltir; ama XP için bu göğüslenebilir bir şeydir, nihayetinde istekleri karşılayamadığı takdirde yazılımın başarılı olduğunu ileri sürmek mümkün değildir.

              5.Saygı

                 Ekibin her bir üyesi diğerlerine saygı duymalıdır. Yaptığı iş ufak bile olsa her ekip üyesi tarafından saygı görmelidir, aksi halde ortaya başarılı bir proje koymak mümkün değildir. 

        XP uygulama pratiklerini anlatacaktım ama yazı çok uzadığından onu yeni yazımda paylaşacağım. Siz bunu okumadan paylaşmış olurum :)

Yazılım Mühendisliği Metodolojileri

       Merhaba arkadaşlar ilk yazımda yazılım mühendisliği ve süreçleri hakkında bilgi vermiştim. Bu yazımda ise size yazılım mühendisliği metotları hakkında bilgi vereceğim. Çok fazla uzatmadan ilk metodumuza bakalım hemen :)

       1. V Model

              

              Şekilde de gördüğümüz gibi modelin sol kısmında üretim etkinlikleri, sağ kısmında ise test etkinlikleri bulunmaktadır. Bu model sayesinde testler yapılırken meydana gelen hataların düzeltilmesi için hangi düzeye dönülmesi gerektiğini rahatlıkla bulabiliriz.

       2. Waterfall (Şelale) Model

              Waterfall modelle yazılım geliştirme süreci analiz, tasarım, kodlama, test, bakım safhalarından oluşur.Bu safhalar doğrusal bir şekilde işler. Bir safha tamamen bitmeden diğerine geçilmez. Her safhanın sonunda doküman oluşur. Bu yüzden doküman güdümlü bir modeldir.

     

       3.Prototip Model

              Bu modelde müşteri işin içine dahil edilir. Gereksinimler anlaşıldığı kadarıyla bir prototip geliştirilir. Müşteriye sunulup onayı alındıktan sonra çalışmaya devam edilir. Prototipin genel amacı müşteri isteklerini netleştirmektir. 

       4.Artırımsal Model

              Bu modelde temel mantık, tüm yapıyı tek bir parça halinde geliştirip teslim etmektense yapı parçalara ayrılır ve her bir parça birbirinden bağımsız geliştirilir, daha sonra bu parçalar birbirine entegre çalışacak hale getirilir.

       

       5.Spiral Model

              

Şekildeki sayıların açıklamaları ise şöyledir:

0: Yaşam döngüsü planı

1: Gerek Planı

2: Geliştirme planı

3: Entegrasyon ve test planı

4: Kapsam

5: Gereklerin belirlenmesi

6: Tasarım ve gerçekleme

7: Entegrasyon, ünite testleri ve kabul testleri

8: Son ürün

Blog Macerası Başlıyor Yazılım Mühendisliği

       Merhaba arkadaşlar bu yazımda - ilk yazım :) - yazılım mühendisliği ve süreçleri hakkında bir şeyler anlatmaya çalışacağım size. 

       Başlangıç olarak yazılım nedir? Yazılım var olan bir problemi çözmek amacıyla bilgisayar dili kullanarak oluşturulmuş anlatımların tamamıdır. Yazılım mühendisliği ise belirli yöntemler ve araçlar kullanarak yazılımları geliştirmeyi, test etmeyi ve bakımlarını yapmayı amaçlayan mühendislik dalıdır.
       
       Yazılım ne olduğunu öğrendiğimize göre şimdi süreçlerini inceleyebiliriz. Yazılım sürecini genel hatları ile Analiz, Tasarım, Kodlama, Test ve Bakım olarak sınıflandırabiliriz.

        Analiz: Bu aşamada yazılımla ilgili planlamalar yapılır. Ne işe yarayacak, gereksinimleri nelerdir, ne kadar bütçe ayrılacak, kimler çalışacak vs.

        Tasarım: Tanımlanan gereksinimlerden sonra sistem tasarımına geçilir. Gereksinim ve istekleri karşılamak için yazılımın özellikleri, yetenekleri ve arayüzleri belirlenir.

        Kodlama: Bu aşamada belirlediğimiz özelliklerin gerçekleşmesini sağlayan kodlar yazılır.

        Test: Yazılan kodların doğru çalışıp çalışmadığı istenilen işi yapıp yapmadığı test edilir.

        Bakım: Teslimi yapılan yazılımda ileride çıkan sorunların düzeltimi veya yeni gelen özelliklerin eklenmesi gibi hizmetler yerine getirilir.