Kullanıcı:ScribeVerse/deneme tahtası

Çevik Yazılım Geliştirme (Agile Software Development) Nedir?

"Ç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ı, aynı zamanda daha çevik yazılım geliştirme süreçleri arayan iş dünyasına yeniden bir yanıt sunmaya ç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].

Çevik yazılım geliştirme, 20 yılı aşkın süredir varlığını sürdürmektedir ve yazılım geliştirme hızının artması ile farklı paydaşlar arasında iş birliğinin güçlenmesi gibi çeşitli iyileştirmelere yol açtığı inkar edilemez^[3]^[4].Proje yöneticilerine ve geliştiricilere çevik yazılım geliştirme nedir diye sorulduğunda, yanıt büyük olasılıkla: Scrum veya XP olacaktır ^[5]. Ancak soruyu daha da derinleştirip bağlamsal faktörler eklediğimizde, örneğin küresel ölçekte dağıtık yazılım geliştirme veya düzenlemelere tabi alanlardaki yazılım geliştirme gibi, yanıt bu kadar basit olmaktan çıkar ^[6] ^[7] ^[8].

Çevik yöntemlerin popülerliği ve kısmen çelişen birçok tanım nedeniyle terminoloji ve kavramlar hakkında büyük bir kafa karışıklığı bulunmaktadır. Bununla birlikte, çoğu zaman insanlar çevik çalıştıklarını sanmakta veya çevikmiş gibi davranmaktadırlar ^[9]. Yani, “çevik yazılım geliştirme” terimiyle ilişkilendirilen yazılım geliştirme süreçleri olduğu gibi, “çevik” olarak algılanan yöntem ve uygulamalar da vardır. Ancak, bu yöntemlerin çoğunun pratikteki kullanımı bağlamsal faktörlerle sınırlıdır ve bazı ortamlarda, çevikle ilişkilendirilen uygulamalar çevik manifesto öncesinde de kullanılmaktaydı ^[10]. Bu durum karşısında, projeler kendi özel ihtiyaçlarına yönelik bireysel süreçler oluşturmaktadır (bunlara hibrit yöntemler diyoruz ^[11]). Yine de şirketler çeşitli nedenlerle “Çevik Dönüşüm”e katılmak istemektedir ve bu nedenle “çevik” yöntemler yaratmaya yönelik bir ilgi oluşmaktadır.

Ç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^[12].

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 ^[13] ile resmi yöntemleri takip etmeye çalışıyordu ^[14]. 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" ^[15]. 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 ^[16].

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 ^[17], 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 ^[18]:

İ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^[19].
Feature-Driven Development (FDD):Özellikle büyük yazılım projeleri için özellik bazlı bir geliştirme süreci sunar ^[20].

Kanban Nedir ?

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. ^[21].

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. ^[22] ^[23]

İş 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 hikayelerle 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 ^[24]^[25].

Kaynakça

^ https://www.agilealliance.org/agile101/
^ https://arxiv.org/pdf/1709.08439
^ T. Dingsøyr, S. Nerur, V. Balijepally and N. B. Moe, "A decade of agile methodologies: Towards explaining agile software development", J. Syst. Softw., vol. 85, no. 6, pp. 1213-1221, 2012
^ https://ieeexplore.ieee.org/abstract/document/9496156
^ P. Hohl et al., "Back to the future: Origins and directions of the “agile manifesto", J. Softw. Eng. Res. Develop., vol. 6, no. 1, 2018.
^ P. Lous, M. Kuhrmann and P. Tell, "Is scrum fit for global software engineering?", Proc. IEEE 12th Int. Conf. Glob. Softw. Eng., pp. 1-10, 2017.
^ B. Fitzgerald, K.-J. Stol, R. O’Sullivan and D. O’Brien, "Scaling agile methods to regulated environments: An industry case study", Proc. Int. Conf. Softw. Eng., pp. 863-872, 2013.
^ M. McHugh, F. McCaffery, V. Casey, A. Mas, A. Mesquida, T. Rout, et al., "Barriers to adopting agile practices when developing medical device software", Proc. Softw. Process Improv. Capability Determination, pp. 141-147, 2012.
^ https://ieeexplore.ieee.org/abstract/document/9496156
^ P. Clarke, R. V. O’Connor and M. Yilmaz, "In search of the origins and enduring impact of agile software development", Proc. ACM Int. Conf. Softw. Syst. Process, pp. 142-146, 2018.
^ P. Tell et al., "What are hybrid development methods made of?: An evidence-based characterization", Proc. IEEE Int. Conf. Softw. Syst. Process., pp. 105-114, 2019.
^ 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.
^ https://en.wikipedia.org/wiki/Kanban_(development)
^ 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

[1] ttps://www.agilealliance.org/agile101/

[2] ttps://arxiv.org/pdf/1709.08439

[3] T. Dingsøyr, S. Nerur, V. Balijepally and N. B. Moe, "A decade of agile methodologies: Towards explaining agile software development", J. Syst. Softw., vol. 85, no. 6, pp. 1213-1221, 2012

[4] ttps://ieeexplore.ieee.org/abstract/document/9496156

[5] P. Hohl et al., "Back to the future: Origins and directions of the “agile manifesto", J. Softw. Eng. Res. Develop., vol. 6, no. 1, 2018.

[6] P. Lous, M. Kuhrmann and P. Tell, "Is scrum fit for global software engineering?", Proc. IEEE 12th Int. Conf. Glob. Softw. Eng., pp. 1-10, 2017.

[7] B. Fitzgerald, K.-J. Stol, R. O’Sullivan and D. O’Brien, "Scaling agile methods to regulated environments: An industry case study", Proc. Int. Conf. Softw. Eng., pp. 863-872, 2013.

[8] M. McHugh, F. McCaffery, V. Casey, A. Mas, A. Mesquida, T. Rout, et al., "Barriers to adopting agile practices when developing medical device software", Proc. Softw. Process Improv. Capability Determination, pp. 141-147, 2012.

[9] ttps://ieeexplore.ieee.org/abstract/document/9496156

[10] P. Clarke, R. V. O’Connor and M. Yilmaz, "In search of the origins and enduring impact of agile software development", Proc. ACM Int. Conf. Softw. Syst. Process, pp. 142-146, 2018.

[11] P. Tell et al., "What are hybrid development methods made of?: An evidence-based characterization", Proc. IEEE Int. Conf. Softw. Syst. Process., pp. 105-114, 2019.

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

[13] ş birliği

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

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

[16] 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.

[17] 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.

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

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

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

[21] ttps://en.wikipedia.org/wiki/Kanban_(development)

[22] 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.

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

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

[25] 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]

[20]

[21]

[22]

[23]

[24]

[25]