Agile
Bu ders dizisi Agile'a yöneliktir, ancak başka yazılım süreci modelleri de vardır. Her birinin yazılım geliştirme yaşam döngüsü (SDLC) boyunca ilerlemenin farklı bir yolu vardır. Bu bölüm Scrum, SDLC, Agile ve Waterfall adı verilen zıt bir yazılım süreci modelini tanımlayarak başlamaktadır. Bunu Scrum (Çevik bir çerçeve) ve dikkate değer Çevik yöntemlerin tartışılması takip etmektedir.
Bu bölüm size kapsamlı bir rehber olmaktan ziyade Agile ve Scrum hakkında bilgi verecektir. Burada tanıtılan konular hakkında daha ayrıntılı bilgi için, bölümün sonundaki yararlanılan Kaynaklar bölümüne bakın.
Yazılım Geliştirme Yaşam Döngüsü
Yazılım geliştirme yaşam döngüsü (SDLC), bir yazılım projesinin beş SDLC aşaması boyunca ilerlemesidir:
- Gereksinimler: Yazılımın neyi, ne kadar iyi ve hangi sınırlamalar veya kısıtlamalar altında yapması gerektiğini belirleme ve yazma.
- Tasarım: Yazılım kodunun nasıl yapılandırılacağının ve kullanıcıların yazılımla nasıl etkileşimde bulunacağının belirlenmesi.
- Uygulama: Yazılımı kodlamak için gereksinimleri ve tasarımı kullanma.
- Test etme: Kodun hatasız yazıldığının (doğrulama) ve yazılımın kullanıcıların veya müşterinin istediği gibi olduğunun (geçerleme) kontrol edilmesi.
- Bakım: Yazılımın mevcut işlevselliğini ve kodunu iyileştirmek.
SDLC aşamalarında seyahat etmenin farklı yolları vardır. Aşamalar arasında seyahat etme modellerine yazılım süreci modelleri denir. Genellikle insanlar Çevik yazılım süreci modelini Şelale modeli ile karşılaştırır.
Çevik Manifesto (Beck vd., 2001) tarafından yönlendirilen Çevik, SDLC boyunca yaklaşık olarak Şekil 1.1'deki gibi hareket eder.
Not. Dikey çizgiler geliştirme döngüsü sınırlarını temsil etmektedir. Bir sonraki geliştirme döngüsü için planlama (R,D) bir önceki döngü sırasında başlar. R, gereksinimler; D, tasarım; I, uygulama; T, test; M, bakım.
Çevik geliştirme döngüleri nispeten kısa ve çok sayıdadır. Sürümler sık ve artımsaldır. Her döngüde, biraz daha fazla çalışan işlevsellik vardır. Scrum çerçevesi (Schwaber & Sutherland, 2020) veya Extreme Programming (XP) (Beck & Andres, 2004; Wells, 2013) gibi çevik bir şekilde yazılım geliştirmenin ve yönetmenin birçok yolu vardır.
Şelale, SDLC boyunca yaklaşık olarak Şekil 1.2'deki gibi hareket eder.
Hareket oldukça doğrusal ve sıralıdır. Her aşama bir önceki aşamanın tamamlanmış olmasına bağlıdır. Çok sayıda dokümantasyon üretilir.
İronik bir şekilde, insanlar genellikle Şelale'yi Şelale'nin büyük kusurlarını açıklayan bir makale ile ilişkilendirir. Royce'un (1970) makalesindeki ikinci şekil, Şelale modelini yedi aşama ve bir aşamadan diğerine aşağı doğru hareketle tasvir etmekte ve bir önceki aşamaya geçişe izin verilmediğini göstermektedir - bir şelaleden yukarı doğru yüzemezsiniz. Makalenin ilerleyen bölümlerinde Royce, Şelale modelinde bir ön program tasarımı yapmak ve uygulamak (daha sonra gerektiğinde gereksinimler aşamasına geri dönmek) gibi değişiklikler önermektedir.
Şelale birçok yazılım projesi için mantıklı olmayabilir, peki ya bir köprü inşa etmek için?
Neden Agile, Diğer Yazılım Süreç Modelleri ve Yazılım Mühendisliği Yöntemleri Önemli?
| 2015 CHAOS raporu 25.000’den fazla yazılım projesi hakkında toplu veriler içermektedir. Yazılım projeleri hakkında bazı bulgular: Çevik projelerin %9’u başarısız oldu Waterfall projelerinin %29’u başarısız oldu Büyük Agile projelerinin %23’ü başarısız oldu Büyük Waterfall projelerinin %42’si başarısız oldu Küçük Agile projelerinin %4’ü başarısız oldu Küçük Şelale projelerinin %11’i başarısız oldu |
- Böylece bir yazılım geliştirme ekibinin ne yaptığını tespit edebilir ve/veya anlayabilirsiniz. Bir ekibe yeni katıldığınızda, farklı yazılım süreci modelleri hakkında genel bir anlayışa sahip olmak, iyi sorular sormanıza, ekibin ne yaptığını görmenize ve ekibinizin ve yöneticilerinizin önünde yetkin görünmenize yardımcı olabilir.
- Böylece yeni bir proje için bir yazılım süreci modeli veya yöntemi seçmeniz gerektiğinde aralarından seçim yapabileceğiniz fikirleriniz olur. Ekibinizin nasıl ilerleyeceğini seçmeniz veya tavsiye etmeniz gerekebilir.
- Böylece bir projenin başı belaya girdiğinde seçebileceğiniz fikirleriniz olur. Standish Group International, Inc. (2015) tarafından hazırlanan CHAOS Raporu'na göre, 2011-2015 mali yılları arasında, veritabanlarındaki 25.000'den fazla yazılım projesi arasında yazılım projelerinin %17 ila %22'si başarısız olmuştur ve proje başarısızlığı olasılığı proje büyüklüğü ile büyük ölçüde artmaktadır. Bazen, doğru yöntemlere sahipseniz bir projeyi kurtarabilirsiniz.
Bu kitap Agile üzerine odaklandığından, bölümün geri kalanında Agile yazılım süreci modeli, bir Agile çerçevesi (Scrum) ve birkaç Agile yöntemi özetlenmektedir.
Agile, Scrum ve Çevik Yöntemler
Agile
Çevik felsefe, Yazılım Geliştirme için Çevik Manifesto (Beck vd., 2001) ile özetlenmiştir:
| Yazılım geliştirmenin daha iyi yollarını, bunu yaparak ve başkalarının yapmasına yardımcı olarak ortaya çıkarıyoruz. Bu çalışma sayesinde değer kazanmaya başladık: –Süreçler ve araçlar yerine bireyler ve etkileşimler. -Kapsamlı dokümantasyon yerine çalışan yazılım. -Sözleşme görüşmeleri yerine müşteri işbirliği. -Bir planı takip etmek yerine değişime yanıt vermek. Yani, sağdaki öğelerde değer olsa da, soldaki öğelere daha fazla değer veriyoruz. |
Neden bu ders dizisinde Agile hakkında bir bölüm var da Waterfall ya da başka bir yazılım süreci modeli hakkında bir bölüm yok? Çünkü çoğu kuruluş yazılım veya BT projeleri için Agile kullanıyor.
Örneğin, 601 katılımcıyla gerçekleştirilen bir HP anketi (Hewlett Packard Enterprise, 2017), kuruluşların birincil yazılım süreci modeli olarak kullandıkları modellerin aşağıdaki şekilde dağıldığını ortaya koymuştur:
- 51%: Çevikliğe Yönelme
- 46%: Hibrit
- 16%: Saf Çevik
- 7%: Şelaleye Doğru Eğilim
- 2%: Saf Şelale
Kuruluşlar neden Agile'ı seçiyor? HP'ye göre, Agile'ı öncelikli olarak benimseyen 403 kuruluştan katılımcıların aşağıdaki yüzdesi Agile geliştirme hakkında aşağıdaki ifadelere katılmıştır:
- 54%: Genellikle birlikte çalışmayan ekipler arasındaki işbirliğini geliştirir.
- 52%: Kuruluşlardaki yazılım kalitesi seviyesini artırır.
- 49%: Müşteri memnuniyetinin artmasıyla sonuçlanır.
- 43%: Pazara sunma süresini kısaltır.
- 42%: Geliştirme maliyetini azaltır.
Scrum
Scrum, yazılım proje yönetimi için iyi bilinen bir çerçevedir. Çevik felsefe ile uyumludur. Örneğin, Scrum Kılavuzu (Scrum için sürekli gelişen kılavuz; Schwaber & Sutherland, 2020), "değişime yanıt verme" değerini yansıtmak için bir yazılım projesinin genellikle iki ila dört hafta uzunluğundaki geliştirme Sprintlerine bölünmesi gerektiğini söyler. Her Sprint'in bir Sprint Planı vardır. Sprint Planları Sprint'ten kısa bir süre önce tanımlanabilir; Ekipler (ve müşterileri) bir seferde sadece birkaç hafta boyunca projenin gelişiminde neler olduğunu bilebilir.
Scrum Ekipleri kendi yöntemlerini, Scrum Kılavuzu'nun mevcut versiyonunun üç kategoriye ayırdığı Scrum çerçevesine uyarlar: ekip, etkinlikler ve eserler. Scrum'a hızlı ve kolay bir giriş yapabilmeniz için, çerçevenin her bir unsuru aşağıda kategorilere göre listelenmiştir.
Ekip. Scrum Ekibi "bir Scrum Master, bir Ürün Sahibi ve Geliştiricilerden oluşur."
- Scrum Master: "Scrum Kılavuzu'nda tanımlandığı şekilde Scrum'ın kurulmasından sorumludur."
- Ürün Sahibi: "Scrum Ekibinin çalışmaları sonucunda ortaya çıkan ürünün değerini en üst düzeye çıkarmaktan sorumludur."
- Geliştiriciler: "Scrum Ekibinde yer alan ve her Sprint'te kullanılabilir bir Artışın herhangi bir yönünü oluşturmayı taahhüt eden kişiler."
Scrum Master'ın odak noktası süreçtir, Ürün Sahibi'nin odak noktası üründür (yazılım) ve Geliştiricilerin odak noktası Scrum süreçlerini takip ederken bir ürün yaratmaktır.
Etkinlikler. Beş Scrum etkinliği vardır:
- Sprint: Bir aydan az süren sabit uzunluktaki geliştirme dönemleri… Yeni bir Sprint, önceki Sprint'in sona ermesinin hemen ardından başlar.
- Sprint Planlama: "Yapılacak işi ortaya koyarak Sprint'i başlatır."
- Günlük Scrum: "Scrum Ekibinin Geliştiricileri için 15 dakikalık bir etkinlik … Sprint Hedefine doğru ilerlemeye odaklanır ve bir sonraki çalışma günü için eyleme geçirilebilir bir plan oluşturur."
- Sprint İncelemesi: "Sprint'in sonucunu incelemek ve gelecekteki uyarlamaları belirlemek için. Scrum Ekibi çalışmalarının sonuçlarını kilit paydaşlara sunar …"
- Sprint Retrospektifi: "kalite ve etkinliği artırmanın yollarını planlamak için . . . Scrum Ekibi son Sprint'in nasıl geçtiğini inceler . . ."
Sprint, her biri Sprint Planlama sırasında belirlenen bir dizi Sprint'te gerçekleşen bir geliştirme dönemidir. Geliştiriciler her gün bir sonraki iş gününü planlamak için 15 dakikalık bir toplantı yapar. Sprintler bir Sprint Gözden Geçirme (ekip ve paydaşlar) ve bir Sprint Retrospektifi (yalnızca ekip) ile sona erer.
Artefaktlar. Üç Scrum artifaktı vardır:
- Ürün İş Listesi: "Ürünü geliştirmek için nelere ihtiyaç duyulduğuna dair ortaya çıkan, sıralı bir liste."
- Sprint İş Listesi: "Sprint Hedefi (neden), Sprint için seçilen Ürün İş Listesi öğeleri seti (ne) ve Artışın teslim edilmesi için eyleme geçirilebilir bir plandan (nasıl) oluşur."
- Artış: "Ürün Hedefine doğru somut bir atlama taşı."
Ürün İş Listesi, Scrum Ekibinin bir süre yapmayı planladığı görevlerin kabaca bir listesini içerir, ancak görevler henüz programlanmamıştır ve ayrıntılı olarak tanımlanmamış olabilir. Sprint Backlog, ekibin üzerinde çalışmaya karar verdiği görevleri içerir ve görevlerin tamamlanmasıyla ilgili ayrıntıları ekler. Artış, ürünü oluşturmaya yönelik bir başarıdır (örneğin, bir özellik uygulamasını bitirmek).
Scrum Kılavuzu (Schwaber & Sutherland, 2020) Scrum çerçeve unsurlarını daha ayrıntılı olarak açıklar ve burada açıklanmayan bazı terimleri tanımlar (örneğin, Sprint Hedefi).
Çevik Yöntemler
Scrum (veya diğer çerçeveler veya diğer yazılım süreci modelleri) içinde kullanılabilecek birkaç önemli Çevik yöntem vardır. Bunlardan birkaçı:
- Scrum panosu: Görevleri veya işleri bir pano üzerinde kartlar halinde organize etmenin ve görselleştirmenin bir yolu. Panoda farklı kategoriler için sütunlar vardır ve her kart bir sütun içine yerleştirilir. Scrum panosu, yapışkan notlar veya dizin kartları içeren fiziksel bir bülten panosu olabilir. Aynı zamanda görev yönetimi yazılımlarının ortak bir özelliğidir.
- Spike: Ekibin bir soruyu yanıtlamasına veya bir geliştirme yolu seçmesine yardımcı olacak bilgileri toplamak için hızlı ve nokta atışı bir araştırma.
- Kullanıcı hikayesi: Bir kullanıcı ihtiyacını karşılama perspektifinden bir yazılım özelliğinin kısa bir açıklaması (örneğin, bu formatı kullanarak: Bir olarak yapabilirim, böylece ). Görevler, öncelikler, zaman/maliyet tahminleri ve kabul kriterleri bir kullanıcı hikayesi ile ilişkilendirilebilir.
Özet
"Çevik" kelimesinin ilişkili değerleri vardır ancak somut bir anlamı yoktur: bu bir felsefedir ve onu takip etmenin tek bir yolu yoktur. Scrum gibi çevik çerçeveler yazılım geliştirme ve proje yönetimi konusunda daha somut rehberlik sağlar. Scrum, sık sık değişen Scrum Kılavuzu'nun (Schwaber & Sutherland, 2020) güncel versiyonu tarafından tanımlanmaktadır.
Sonraki Ders: Proje Yönetimi ve Ekip Çalışması
Yorumlar
Yorum Gönder