Atik yazılım geliştirme

	Yazılım geliştirme süreci
	Etkinlikler ve adımlar
	Gereksinimler \| Mimari \| Tasarım \| Yaşama geçirme \| Sınama \| Konuşlanma
	Modeller
	Agile \| Cleanroom \| Iterative \| RAD \| RUP \| Spiral \| Waterfall \| XP \| Scrum
	Supporting disciplines
	Configuration management \| Documentation \| Software quality assurance (SQA) \| Project management \| User experience design

"Çevik,“çevik olma kalitesi; harekete hazır olma; çeviklik, hareket yeteneği, harekette beceri” anlamına gelir. Yazılım geliştirme yöntemleri, daha hafif ve daha hızlı çalışmaktadır.^[1] Bu, özellikle hızla büyüyen ve değişken olan internet yazılım sektörü ile gelişmekte olan mobil uygulama ortamı için geçerlidir. Mobil uygulama sektörü kullanıcı beklentilerinin sürekli değiştiği ve yeni özelliklerin hızla eklenmesi gereken bir alan olduğundan, çevik yöntemler burada oldukça kullanışlıdır.^[2]

Atik yazılım geliştirme ya da çevik yazılım geliştirme, basit prensiplere dayanan yazılım geliştirme metotları gruplarının genel adıdır. Bu metotlar genelde alışılmış denetim ve uyum süreçlerini teşvik eden proje yönetim işlemlerine önayak olurlar.^[3] Bu yaklaşım; takım çalışmasıyla gelen liderlik psikolojisi, kendi kendini düzene sokma (örgütleme), sorumluluk, yüksek kalitedeki yazılımların hızlı dağıtımını onaylayan en iyi mühendislik örnekleri ve iş yaşamında müşteri ihtiyaçlarıyla şirketlerin temel amaçlarını, vizyonlarını koordine etme işlevi de görmektedir.

Çevik yazılım metodolojilerinin kökeni 1957 yıllarındaki IBM'deki yazılım geliştirme çalışmalarına dayanmaktadır. Bu çalışmalar daha sonra E. A. Edmonds tarafından arttırımlı yazılım geliştirme olarak tanımlanmış ve 1974 yılında “Uyumlu Sistemler İçin Yazılım Geliştirme” başlıklı bir makale ile tanıtılmıştır. 1990'lı yıllar ise Şelale modelinin hantal bir sistem olduğu iddia edilerek onun yerine daha hızlı ve çevik yazılım geliştirme metodolojileri sunmaya çalışılan yıllar olarak geçmiştir.^[4] 2001 yılının Şubat ayında yazılım dünyasının önde gelen 17 ismi Utah’da bir araya gelerek yazılım geliştirme üretkenliğini arttırmaya yönelik 2 günlük beyin fırtınası yapmışlar ve “Çevik Yazılım Geliştirme Manifestosu” ve Çevik Yazılımın Prensipleri'ni yayınlamışlardır.

Manifesto

Manifesto, daha iyi bir yazılım geliştirmenin yöntemlerini açıklayan 4 ana madde ve 12 temel ilkeden oluşmaktadır.^[5]

Ana Maddeler

Bireyler ve etkileşimler, süreçler ve araçlardan;
çalışan yazılım, kapsamlı dokümantasyondan;
müşteri ile işbirliği, kontrat görüşmesinden;
değişikliklere yanıt vermek, bir planı takip etmekten önce gelir.

Temel İlkeler

En önemli önceliğimiz değerli yazılımın erken ve devamlı teslimini sağlayarak müşterileri memnun etmektir.
Değişen gereksinimler yazılım sürecinin son aşamalarında bile kabul edilmelidir. Çevik süreçler değişimi müşterinin rekabet avantajı için kullanır.
Çalışan yazılım, tercihen kısa zaman aralıkları belirlenerek birkaç haftada ya da birkaç ayda bir düzenli olarak müşteriye sunulmalıdır.
İş süreçlerinin sahipleri ve yazılımcılar proje boyunca her gün birlikte çalışmalıdırlar.
Projelerin temelinde motive olmuş bireyler yer almalıdır. Onlara ihtiyaçları olan ortam ve destek sağlanmalı, işi başaracakları konusunda güven duyulmalıdır.
Bir yazılım takımında bilgi alışverişinin en verimli ve etkin yöntemi yüz yüze iletişimdir.
Çalışan yazılım ilerlemenin birincil ölçüsüdür.
Çevik öğrenme süreçleri sürdürülebilir geliştirmeyi teşvik etmektedir. Sponsorlar, yazılımcılar ve kullanıcılar sabit tempoyu sürekli devam ettirebilmelidir.
Teknik mükemmeliyet ve iyi tasarım konusundaki sürekli özen çevikliği artırır.
Sadelik, yapılmasına gerek olmayan işlerin mümkün olduğunca arttırılması sanatı, olmazsa olmazlardandır.
En iyi mimariler, gereksinimler ve tasarımlar kendi kendini örgütleyen takımlardan ortaya çıkar.
Takım, düzenli aralıklarla nasıl daha etkili ve verimli olabileceğinin üzerinde düşünür ve davranışlarını buna göre ayarlar ve düzenler.

Çevik Yöntemlerin Çeşitleri

1) Scrum

Scrum temel olarak yazılım ve ürün geliştirme sürecini yönetmek ve kontrol etmek için adımlar sağlayan çevik, hafif bir çerçevedir. Scrum, Yinelemeli model ile Artımlı modelin birleşimidir, çünkü nesne yönelimli yazılım geliştirme özellikleri açısından yapılar ardışık ve artımsaldır. Scrum, gelişim hızını artırmak, bireysel ve kurumsal mottoyu uyumlu hale getirmek, performansa odaklanan bir kültür tanımlamak, hissedar değeri yaratmayı desteklemek, her seviyede iyi bir performans iletişimine sahip olmak, bireysel gelişimi ve yaşam kalitesini artırmak için tasarlanmıştır. Scrum son birkaç yılda popülerliğini artırdı ve oldukça faydalı olduğunu kanıtladı ancak her zaman kullanılacak bir yöntem değildir^[6].

2)Crystal

Crystal, proje boyutu, karmaşıklığı, kritiklik derecesi ve ekipteki kişi sayısına göre farklı yazılım projelerinde kullanılabilecek çevik yazılım geliştirme metodolojilerinden oluşan bir koleksiyondur. Bu yöntemler, 1990'ların başında Alistair Cockburn tarafından IBM'de çalışırken geliştirilmiştir. Farklı projelerde çalışan ekiplerle röportajlar yaparak ekiplerin izlediği en iyi uygulamaları bulmayı amaçladı. Cockburn, bu ekiplerin başarılı yazılım geliştirmek için resmi metodolojileri ya da belirli teknolojileri kullanmadıklarını, ancak projeyi tartışmak için sık sık iletişim kurduklarını gözlemledi. Öte yandan, başarısız olan veya geciken proje ekipleri, az ^[7] ile resmi yöntemleri takip etmeye çalışıyordu ^[8]. Bu gözlem, Cockburn'ün takım üyeleri arasındaki sık iletişimin yazılım başarısını artırabileceği sonucuna varmasına yardımcı oldu. Cockburn’un felsefesine göre,"Yazılı dokümantasyonu yüz yüze etkileşimle değiştirebildiğiniz ölçüde, yazılı 'vaat' notlarına olan bağımlılığı azaltabilir ve sistemin teslim edilme olasılığını artırabilirsiniz" ^[9]. Crystal yöntemleri, sık sık çalışan yazılım teslim etmek için süreçten ziyade insanlar ve insanlar arasındaki iletişime odaklanır.

3)Extreme Programming (XP)

Extreme Programming (XP), çevik yazılım geliştirme yöntemleri arasında, özellikle yüksek kaliteli yazılım üretimine ve sık teslimatlara odaklanan bir metodolojidir. 1990'ların sonlarında Kent Beck tarafından geliştirilmiştir ve hızlı değişen gereksinimlere karşı yüksek müşteri memnuniyetini hedefler. XP, yazılım geliştirme sürecinde daha iyi iletişim, daha yüksek kalite ve daha hızlı teslimat sağlamak için bir dizi uygulama ve prensip içerir ^[10].

4)Lean Yazılım Geliştirme

Lean Manufacturing (Yalın Üretim), Toyota’nın geliştirme grubu tarafından ortaya konulmuş bir yaklaşımdır. Yalın Üretim Sistemi, müşterilerin taleplerini en az kaynakla ^[11], en kısa zamanda, en ucuz ve eksiksiz olarak karşılamayı amaçlayan bir sistemdir. Bu olumlu özellikler sayesinde Yalın Üretim, otomotiv sektörünün dışındaki diğer alanların da ilgisini çekmiş ve farklı disiplinlere uygulanmaya başlanmıştır. Yalın üretim, aşağıdaki ilkelere dayanmaktadır ^[12]:

İsrafı giderme (Eliminate waste)
Bütünü optimize etme (Optimize the whole)
Kalite ile geliştirme (Build quality in)
Sürekli öğrenme (Learn constantly)
Hızlı teslim (Deliver fast)
Takımı güçlendirme (Empower the team)
Mümkün olduğunca geç karar verme (Decide as late as possible)

6)Diğer Çevik Yöntemler

Kanban: Detaylı bilgi aşağıda işlenecektir.
Dynamic Systems Development Method (DSDM): Prototipleme ve iş birliğine odaklanan, kapsamı sabitlenmiş ancak zaman ve kaynak bakımından esnek bir yaklaşımdır^[13].
Feature-Driven Development (FDD):Özellikle büyük yazılım projeleri için özellik bazlı bir geliştirme süreci sunar ^[14].

Kanban Nedir?

A Kanban board

Kanban (看板, anlamı tabela veya Reklam Panosu) insan sistemlerinde iş yönetimi ve iyileştirilmesi için bir yalın yöntemdir. Bu yaklaşım, talepleri mevcut kapasiteyle dengeleyerek ve sistem düzeyindeki Üretim yönetimini iyileştirerek işleri yönetmeyi amaçlar. İş öğeleri, katılımcılara sürecin başlangıcından bitişine kadar ilerlemeyi göstermek için görselleştirilir. Genellikle bir kanban panosu aracılığıyla yapılır. İş, talep edildiğinde sürece zorla dahil edilmez; bunun yerine, kapasite elverdiği ölçüde çekme Strateji'si kullanılarak sürece alınır.

Kanban’ın Çevik Yazılım Geliştirmedeki Rolü

Kanban, yazılım geliştirme sürecinde iş akışını görselleştirerek işlerin daha verimli ve düzenli bir şekilde ilerlemesini sağlar. Çevik projelerde, Kanban panoları aracılığıyla iş adımları (ör. "Yapılacaklar", "Yapılıyor", "Tamamlandı") takip edilir ve işlerin durumu net bir şekilde gözlemlenir.Kanban daha çok bakım ve destek süreçlerinde, sürekli teslimat gerektiren projelerde ve sürekli değişime ihtiyaç duyan işlerde tercih edilir.^[15].

Kanban’ın Avantajları ve Sınırlamaları

Avantajları:

İş Akışını Görselleştirir: Kanban panoları, projedeki tüm görevlerin durumu ve ilerleyişi hakkında net bir görünüm sağlar.
Esnek ve Uyarlanabilir: Çevik projelerde değişikliklere kolaylıkla adapte olur ve sürekli teslimat sağlar.
Sürekli İyileştirme: Kanban, sürekli geri bildirim döngüleriyle süreçte iyileştirmeler yapmayı teşvik eder.

Sınırlamaları:

İşlerin Önceliklendirilmesi Zorlaşabilir: Sürekli akış olduğundan, işlerin hangi sırayla yapılacağı konusunda belirsizlik olabilir.
Uygulama Disiplini Gerektirir: İş akışını sürekli takip etme ve sınırlamalara (WIP) uyma disiplini gerektirir, aksi takdirde süreç karmaşık hale gelebilir.
Bazı Projelere Uygun Olmayabilir: Özellikle sabit teslim süreli veya katı planlamaya dayalı projelerde Kanban yeterince etkili olmayabilir.^[16]^[17]

İş Akışının Yönetimi

Kanban, iş akışını doğrudan kanban panosu üzerinden yönetir. Geliştirme adımları için belirlenen WIP (devam eden iş) limitleri, geliştirme ekiplerine yaygın iş akışı sorunları hakkında anında geri bildirim sağlar.Bir Kanban panosu düzeninde, iş akışını görsel olarak organize etmek için "swimlane"ler (yüzme şeritleri) kullanılır; bu, süreçteki farklı aşamaların net ve odaklı bir şekilde düzenlenmesini sağlar. Verimli bir iş akışı yönetimi için gereksinimler, geliştirme, test ve kapalı/tamamlanmış görevler gibi temel aşamalar için ayrı swimlane'lerin bulunması önemlidir. Özellikle test hikayeleri her zaman belirlenen "Test" swimlane'inde yer almalıdır. Bu ayrım, test aktivitelerinin kolayca izlenmesini sağlar ve geliştirme veya diğer aşamalardaki hikâyelerle karışmasını önler. Test görevlerinin kendi swimlane'lerinde tutulması, ekiplerin darboğazları hızlıca tanımlamalarına, öncelikleri belirlemelerine ve test sürecinin bütünlüğünü korumalarına yardımcı olur. Bu yapı, iş akışlarını daha net hale getirir ve ekip işbirliğini artırır. Bu iş akışı kontrolü her adım için benzer şekilde çalışır. Sorunlar görsel olarak hemen ortaya çıkar ve yeniden planlama sürekli olarak yapılabilir. İş yönetimi, ekip üyelerinin her zaman görebileceği ve takip edebileceği şekilde devam eden işleri sınırlayarak mümkün hale gelir ^[18]^[19].

Kaynakça

^ "What is Agile? | Agile 101 | Agile Alliance". www.agilealliance.org. 29 Haz 2015.
^ Pekka Abrahamsson, Outi Salo, Jussi Ronkainen and Juhani Warsta. "Agile Software Development Methods: Review and Analysis". Erişim tarihi: 14 Aralık 2024.
^ "Arşivlenmiş kopya". 31 Temmuz 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 27 Nisan 2022.
^ "Arşivlenmiş kopya". 27 Nisan 2022 tarihinde kaynağından arşivlendi. Erişim tarihi: 27 Nisan 2022.
^ "Arşivlenmiş kopya". 1 Mayıs 2022 tarihinde kaynağından arşivlendi. Erişim tarihi: 27 Nisan 2022.
^ Schwaber. K., and Mike Beedle, Agilè Software Development with Scrum.USA: 2002
^ iş birliği
^ D. Cohen, M. Lindvall, and P. Costa, “An introduction to agile methods.” ADVANCES IN COMPUTERS, vol. 62, 62, pp.1- 66, 2004.
^ J. A. Highsmith, “Agile software development ecosystems.” Vol. 13, Addison-Wesley Professional, 2002.
^ Erickson, J., Lyytinen, K., & Siau, K. (2005). Agile modeling, agile software development, and extreme programming: the state of research. Journal of Database Management (JDM), 16(4), 88-100.
^ Kitchenham, B. A., Dyba, T., and Jorgensen, M., “Evidence-Based Software Engineering”, Proc. of the 26th International Conference on Software Engineering (ICSE '04), Scotland, UK, pp. 273-281.
^ Poppendieck, M., Lean Software Development, Addison Wesley, 2003.
^ Stapleton, J. (1997). DSDM, dynamic systems development method: the method in practice. Cambridge University Press.
^ Palmer, S. R., & Felsing, M. (2001). A practical guide to feature-driven development. Pearson Education.
^ "Kanban (development)". 9 Ara 2024 – Wikipedia vasıtasıyla.
^ Ahmad, M. O., Markkula, J., & Oivo, M. (2013, September). Kanban in software development: A systematic literature review. In 2013 39th Euromicro conference on software engineering and advanced applications (pp. 9-16). IEEE.
^ Kirovska, Nevenka and Saso Koceski. “Usage of Kanban methodology at software development teams.” (2015).
^ Anderson, David J. (April 2010). Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press. ISBN 978-0-9845214-0-1
^ Brechner, Eric (2015). Agile Project Management with Kanban. Microsoft Press. p. 160. ISBN 978-0735698956

Ayrıca bakınız

[1] "What is Agile? | Agile 101 | Agile Alliance". www.agilealliance.org. 29 Haz 2015.

[2] Pekka Abrahamsson, Outi Salo, Jussi Ronkainen and Juhani Warsta. "Agile Software Development Methods: Review and Analysis". Erişim tarihi: 14 Aralık 2024.

[3] "Arşivlenmiş kopya". 31 Temmuz 2018 tarihinde kaynağından arşivlendi. Erişim tarihi: 27 Nisan 2022.

[4] "Arşivlenmiş kopya". 27 Nisan 2022 tarihinde kaynağından arşivlendi. Erişim tarihi: 27 Nisan 2022.

[5] "Arşivlenmiş kopya". 1 Mayıs 2022 tarihinde kaynağından arşivlendi. Erişim tarihi: 27 Nisan 2022.

[6] Schwaber. K., and Mike Beedle, Agilè Software Development with Scrum.USA: 2002

[7] ş birliği

[8] D. Cohen, M. Lindvall, and P. Costa, “An introduction to agile methods.” ADVANCES IN COMPUTERS, vol. 62, 62, pp.1- 66, 2004.

[9] J. A. Highsmith, “Agile software development ecosystems.” Vol. 13, Addison-Wesley Professional, 2002.

[10] Erickson, J., Lyytinen, K., & Siau, K. (2005). Agile modeling, agile software development, and extreme programming: the state of research. Journal of Database Management (JDM), 16(4), 88-100.

[11] Kitchenham, B. A., Dyba, T., and Jorgensen, M., “Evidence-Based Software Engineering”, Proc. of the 26th International Conference on Software Engineering (ICSE '04), Scotland, UK, pp. 273-281.

[12] Poppendieck, M., Lean Software Development, Addison Wesley, 2003.

[13] Stapleton, J. (1997). DSDM, dynamic systems development method: the method in practice. Cambridge University Press.

[14] Palmer, S. R., & Felsing, M. (2001). A practical guide to feature-driven development. Pearson Education.

[15] "Kanban (development)". 9 Ara 2024 – Wikipedia vasıtasıyla.

[16] Ahmad, M. O., Markkula, J., & Oivo, M. (2013, September). Kanban in software development: A systematic literature review. In 2013 39th Euromicro conference on software engineering and advanced applications (pp. 9-16). IEEE.

[17] Kirovska, Nevenka and Saso Koceski. “Usage of Kanban methodology at software development teams.” (2015).

[18] Anderson, David J. (April 2010). Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press. ISBN 978-0-9845214-0-1

[19] Brechner, Eric (2015). Agile Project Management with Kanban. Microsoft Press. p. 160. ISBN 978-0735698956

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]