agi̇le yöntemleri̇

AGĠLE YÖNTEMLERĠHAZIRLAYAN: FATĠH SOYSAL

AGILE YAZıLıM GELIġTIRME

Hepimiz içinde bulunduğumuz projelerde çeĢitli sorunlarla karĢı karĢıya kalıyoruz. Bu sorunlar projelerin

zamanında bitirilememesine, müĢterinin isteklerine uymayan yazılımlar üretilmesine ve hatta projelerin

baĢarısız olmasına bile sebep olabiliyorlar. ĠĢte bu sunumda yazılım geliĢtirme süreçlerinden

kaynaklanan sorunlara çözüm olarak üretilen Agile Yazılım Geliştirme'den bahsedeceğim.

AGILE YAZıLıM GELIġTIRME

AraĢtırmalara göre ülkemizdeki yazılım projeleri yönetimsel eksiklilerden dolayı ancak %50 baĢarı ve

memnuniyet ile tamamlanabilmektedir. Ne yazık ki, bu ciddi iĢ gücü kaybı ve bu verimsiz üretim ile Türk

yazılım sektörünün dünya devleriyle yarıĢabilmesi pek mümkün değildir.

GeçmiĢe bakarsak, Avrupa ve Amerika’daki büyük Ģirketler de bu dönemi yaĢamıĢlar, daha verimli

projeler üretmek üzere çeĢitli yöntemler denemiĢler ve çoğu Ģirket yönetimde ve uygulamada en baĢarılı

buldukları “Agile” (çevik) yazılım metodolojilerini benimsemiĢlerdir. Bu metodolojiler sayesinde, artan

verimlilik ve esneklik ile projelerin kalitesini arttırmıĢ ve baĢarı oranlarını %80’lere çıkartmayı

baĢarmıĢlardır.

AGĠLE NEDĠR?

“Agile” (çevik), dünya üzerinde kabul edilen yöntemler arasında en hızlı ve güvenli proje geliştirme

metodolojisidir.

Halen, birçok Ģirket tarafından hızla kullanıma geçirilmektedir. Ancak, ülkemizde henüz yaygın olarak

kullanılmamakta ve birçok Ģirketin öz kaynakları ve zamanı çeĢitli aksaklıklar nedeniyle boĢa

harcanmaktadır.

Yazılım geliĢtirmek, yeni bir ürün yaratmaya benzer ve yazılım projeleri süreç içerisinde değişerek

Ģekillenir. Projelerde karĢılaĢılacak olan birçok problem, yazılım projesi doğası gereği baĢlangıçta

öngörülebilir olmaktan uzaktır. Bu yüzden, yazılım geliĢtirirken alıĢılagelmiĢ klasik seri üretim metotları

birçok koĢulda baĢarılı çözümler üretmekten uzaktır ve baĢarı için daha esnek metodlara ihtiyaç

duyulmaktadır.

PROJELERINIZDE SıKÇA KARġıLAġTıĞıNıZ SORUNLAR

NELERDIR?

Teknolojinin çok hızlı geliĢmesi ve bu yeniliklerin projelere uygulanamaması

MüĢterilerin proje baĢlangıcında büyük resmin tamamını yani bütün gereksinimleri ortaya koyamamaları

MüĢterilerin gereksinimlerinin çok çabuk ve sık değiĢmesinden dolayı müĢterilerin güncel ihtiyaçlarına

cevap veremeyen bir yazılım ortaya çıkması

Projelerin yönetiminin gittikçe daha zor ve karmaĢık hale gelmesi

ĠĢte bu sorunlardan dolayı, yazılım geliĢtirmek müşteri odaklı olmayı ve değişikliklere uyum

sağlayabilmeyi gerektirir. Bunun aksine klasik yöntemlerle ele alınan yazılım projeleri değiĢime uyum

sağlamakta güçlük çekerek kırılacak ve istenen baĢarıyı elde etmekte zorlanacaktır.

Kısacası, yazılım projeleri çoğunlukla yeni bir ürün yaratmaktır ve yeni bir ürün yaratma sürecinde

değiĢiklikler kaçınılmazdır. Yazılım projelerinin bu gerçeklikler doğrultusunda ele alınarak yönetilmeleri

gerekir.

MANIFESTO

Dünyanın her köĢesindeki yazılım geliĢtirme takımı gibi bu sorunlarla karĢılaĢan 17 profesyonel

Amerika'nın Utah eyaletinde çözüm üretebilmek, müşteri memnuniyetini arttırabilmek ve başarısız

olan projelerin oranını düşürmek için 2001 yılının ġubat ayında bir araya geliyorlar ve bir manifesto

ortaya koyuyorlar;

AGILE

The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Copyright 2001, the Agile Manifesto authors

MANIFESTO AMACı

Manifestonun açıkça belirttiği gibi Agile geliĢtirme sürecinin amacı;

Plan, dökümantasyon, proses ve araçlardan ziyade müĢteri memnuniyeti, çalıĢan yazılım, uyumlu yazılım

geliĢtirme takımı ve müĢteri isteklerinde oluĢan değiĢikliklere göre kısa zamanda geliĢtirilebilecek yazılımlar

üretmektir. Buradan Agile yazılım geliĢtirmenin plansız, dökümansız yazılım geliĢtirmeyi teĢvik ettiği

sonucuna varmamak gerekiyor. Agile yazılım geliĢtirme sadece bunlardan daha önemli kavramların

olduğunu vurgulamakta. "Agile yazılım geliştirme" süreçlerin, dökümanların ve dizaynların proje

baĢlangıcında tümüyle tanımlanmasını değil, geliĢtirme aĢamasında karĢılaĢılan ve değiĢen koĢullara göre

gerekli kararların verilmesi gerektiğini savunuyor.

AGĠLE PRENSIPLERI

1- Ġlk öncelik, sürekli, kaliteli yazılım teslimatıyla müşteri memnuniyetini sağlamaktır.

2- Proje ne kadar ilerlemiĢ olursa olsun değiĢiklikler kabul edilir. Çevik yazılım süreçleri değiĢiklikleri

müşteri avantajına dönüĢtürürler.

3- Mümkün olduğunca kısa zaman aralıklarıyla (2-6 hafta arası) çalıĢan, kaliteli yazılım teslimatı yapılır.

4- Analistler, uzmanlar, yazılımcılar, testçiler vs. tüm ekip elemanları bire bir iletiĢim halinde, birlikte

çalıĢırlar.

5- Ġyi projeler motivasyonu yüksek bireyler etrafında kurulur. Ekip elemanlarına gerekli destek

verilmeli, ihtiyaçları karĢılanarak proje ile ilgili ekiplere tam güvenilmelidir.

AGĠLE PRENSIPLERI

6- Ekip içerisinde kaliteli bilgi akıĢı için yüz yüze iletişim önemlidir.

7- ÇalıĢan yazılım, projenin ilk geliĢim ölçütüdür.

8- Çevik süreçler mümkün olduğunca sabit hızlı, sürdürülebilir geliĢtirmeye önem verir.

9- Güçlü teknik alt yapı ve tasarım çevikliği arttırır.

10- Basitlik önemlidir.

11- En iyi mimariler, gereksinimler ve tasarımlar kendi kendini organize edebilen ekipler tarafından yaratılır.

12- Düzenli aralıklarla ekipler kendi yöntemlerini gözden geçirerek verimliliği arttırmak için gerekli

iyileĢtirmeleri yaparlar.

AGĠLE YÖNETĠMĠNĠN GETĠRĠLERĠ

Düşük Risk:

Tekrarlanan yazılım geliĢtirme metotları, proje risklerini azaltıp baĢarıyı arttırmakta ve hata oranlarını

düĢürerek verimliliği yükseltmektedir. Bunun arkasında yatan en temel etken, daha projenin baĢlarında

geliĢtirilen program parçacıkları sayesinde, proje ekibinin yetkinliklerinin ve projede kullanılan her türlü

araçların önceden denenerek eksiklerinin görülebilmesidir.

Ayrıca, parçalı geliĢtirme süreci içerisinde proje hızlı olarak Ģekillenmekte ve proje baĢlangıcında fark

edilemeyen riskler ciddi sorunlara yol açmadan önce görülebilir hale gelmektedir.


Değişimin Teşvik Edilmesi:

En baĢta belirttiğimiz gibi, yazılım projelerinde değişiklik kaçınılmazdır. Orta çaplı projeler dahi

proje süresince baĢlangıçlarına göre %30 oranlarında değiĢeme uğramaktadır. Bu nedenle,

değişim yazılım projelerinin doğasıdır ve bu gerçeklik çevik metodolojilerin de üzerinde

önemle durduğu bir etkendir.

Agile metodolojiler değiĢime karĢı gelmek yerine değiĢimi müĢteri avantajına dönüĢtürmeye

yönelik olarak çalıĢırlar. Çevik metodolojiler, önerdiği parçalı yazılım üretimi ve her adımdaki

güçlü bilgi alıĢ veriĢiyle, değiĢim gereksinimlerinin mümkün olduğunca projelerin baĢlangıç

adımlarında fark edilmesini ve projenin değiĢime hızlı bir Ģekilde adapte olabilmesini sağlarlar.


Karmaşıklığın Yönetimi:

Yazılım projelerinin hacimleri büyüdükçe karmaşıklıkları artar ve buna bağlı olarak hata oranları da artar.

Çevik yöntemler ise projeleri, daha kolay yönetilebilir küçük parçalara bölerek ele alırlar.

Böylece, projelerin büyüklüğü ne olursa olsun, küçük parçalara ayrılarak ele alınan projeler için karmaĢıklık

en düĢük seviyeye indirilir.

Sürekli Yazılım Teslimi:

Agile metodolojilerde her yineleme sonunda çalıĢır bir programcık meydana getirilmektedir. Projenin

baĢlarından itibaren devam ederek büyüyen bu parçacıklar, müĢterilere elle tutulur aĢamalar olarak

sunulmakta ve bu da müşteri memnuniyetini arttırmaktadır. Yapılan araĢtırmalar, müĢterilerin

tamamlanmıĢ ama çalıĢmayan programlar yerine, çalıĢır durumda ama tamamlanmamıĢ programları tercih

ettiklerini göstermiĢtir.


Müşteri ihtiyaçlarına daha iyi cevap veren çözümler:

Yinelemeler arasında gerçekleĢtirilen fikir alıĢ veriĢleri, çevik yöntemlerin değiĢikliğe olan yatkınlığı ve

müĢteri odaklı yaklaĢımları sayesinde, projeler, müşteriler ile birlikte değişerek gelişmekte ve proje

sonunda da müĢteri ihtiyacını en iyi derecede karĢılayabilecek programlar ortaya çıkmaktadır.

MüĢterilerin çoğunlukla proje baĢlangıcında tam olarak ne istediklerine dair net birer fikirleri yoktur ve

istekler, projenin geliĢim süreci ile birlikte Ģekillenmektedir. Bu gerçeklik karĢısında, çevik yöntemler müĢteri

odaklı ve esnek yapısıyla, müĢteri memnuniyetini en üst seviyede tutmayı baĢarabilmektedirler.

SCRUM

Scrum'u Agile yazılım geliĢtirme metodunun bahsettiğimiz prensiplerine uygun olarak geliĢtirilmiĢ, en

yaygın kullanılan, tasarlanmıĢ bir yöntem olarak tanımlayabiliriz. Ayrıca XP ve Lean Software

Development gibi yöntemler de mevcuttur. Scrum diğer Agile yöntemleri gibi çok fazla kuralı olmayan,

sadece belirli prensipleri olan ve kolayca projelere uygulanabilecek bir yöntemdir.

Scrum'ı sadece yazılım geliĢtirmek için değil hayatta karĢılaĢabileceğiniz her türlü olaya

uygulanabilecek bir yöntem olarak düĢünebilirsiniz. ġimdi kısaca Ģemada geçecek olan kavramları

genel bir Scrum planlaması ve akıĢı içinde adım adım aktaralım.

SCRUM YÖNTEMININ GENEL AKıġ ġEMASı

SCRUM PLANLAMASı

1- Roller (Roles)

Ürün Sahibi (Product Owner)

Scrum Yöneticisi (Scrum Master)

Takım Üyesi (Team Member)

SCRUM PLANLAMASı

2- Toplantılar (Meetings)

Sprint Planlama (Sprint Planning)

Sprint gözden geçirme (Sprint Review)

Günlük Scrum toplantısı (Daily Scrum)

SCRUM PLANLAMASı

3- Kavramlar (Artifacts)

Ürün gereksinim dökümanı (Product Backlog)

Sprint dökümanı (Sprint Backlog)

Sprint kalan zaman grafiği (Burndown Chart)

SCRUM PLANLAMASı

Projenin baĢlangıç adımı olarak yazılım gereksinimlerinin (requirements, features) ürün sahibi

tarafından ürün gereksinim dökümanına yazılmasını düĢünebiliriz. Bu dökümanın sahibi ürün

sahibidir ve gereksinimleri önceliklerine (priority) göre sıralar. Ürün sahibi bu dökümana yazılım

geliĢtirme süresince eklemeler ve çıkarmalar yapıp öncelikleri değiĢtirme hakkına sahiptir. Böylece ürün

sahibi değiĢen ihtiyaçlarına uygun olarak bir yazılıma sahip olma Ģansını yakalamıĢ olur.

SCRUM PLANLAMASı

Gereksinimler belirlendikten sonra yazılım geliĢtirme takımı Sprint planlama toplantısında bir sonraki

Sprint'de geliĢtirilmek üzere ürün gereksinim dökümanından ürün sahibinin belirlediği yüksek

öncelikli gereksinimleri seçerek Sprint dökümanına aktarırlar. Bu toplantıya Scrum yöneticisi, ürün

sahibi ve takım üyeleri katılırlar ve Sprint süresi en az 2 en fazla 4 hafta olarak belirlenir.

Sprint planlama toplantılarını Scrum yöneticisi yönetir. Scrum yöneticisinin asıl görevi Scrum'un

temel prensiplerinin projeye uygulanmasını, bu prensiplerin takım üyelerince doğru Ģekilde

anlaĢılmasını sağlamaktır. En önemli görevi ise Sprint süresince takımı dıĢardan gelebilecek etkilere

karĢı korumak ve takımın ihtiyaçlarını karĢılamaktır.

SCRUM PLANLAMASı

Scrum her Sprint'in sonunda mutlaka ürün sahibine kullanabileceği bir yazılım sağlamayı hedefler, bundan

dolayı planlanan Sprint süresi (2-4 hafta) asla uzatılmaz. Fakat eğer bir gereksinim belirlenen Sprint süresi

içerisinde gerçekleĢtirilemeyecekse bir sonraki Sprint'e aktarılabilir. Ve aynı Ģekilde eğer Sprint süresi

bitmeden Sprint dökümanındaki gereksinimlerin hepsi tamamlanmıĢsa ürün gereksinim dökümanından

yeni gereksinimler Sprint dökümanına aktarılabilir.

Sprint planlama toplatısında belirlenen gereksinimler takım üyelerince küçük görevlere (tasks) bölünerek

takım üyelerine geliĢtirilmek üzere atanır. Scrum takımı geleneksel yazılım geliĢtirme süreçlerinden farklı

olarak kesin rollere (architect, tester, developer, disagner vb.) sahip değildir. Scrum takımındaki bütün üyeler

çapraz görevlerde yer alabilirler, böylece kodun tek bir kiĢiye bağımlılığı riski ortadan kaldırılmıĢ olur. Sprint

dökümanının sahibi bu sefer ürün sahibi değil yazılım geliĢtirme takımıdır, dolayısıyla bu dökümana ürün

sahibi değil takım üyeleri katkıda bulunurlar.

SCRUM PLANLAMASı

Sprint dökümanına aktarılan gereksinimlerin tahmini geliĢtirme süresi saat bazında takım üyelerince

belirlenir ve Sprint boyunca sürekli olarak tahmini bu zamanlar güncellenerek Sprint kalan zaman

grafikleri (burndown chart) oluĢturulur. Böylece Sprint süresince ürün sahibi ve scrum yöneticisi

Sprint'in genel gidiĢi hakkında bilgi sahibi olur, aynı zamanda takım elemanları da kalan iĢ sürelerini ve

harcadıkları zamanı takip edebilirler.

SCRUM PLANLAMASı

Scrum'un belki de verimliliği artıran en önemli kavramlarından biri de günlük Sprint toplantılarıdır. Bu

toplantılar her gün belirli saatlerde farklı bir takım üyesinin liderliğinde ayak üstü yapılır ve en fazla 15

dakika sürer. Bu toplantılarda her takım üyesi Ģu 3 soruya cevap verir;

Dün ne yaptım?

Bugün ne yapacağım?

Önümde olan engeller ve karĢılaĢtığım sorunlar neler?

SCRUM PLANLAMASı

Bu toplantılara herkesin zamanında ve davet edilmeden katılması ve uzun sürmemesi çok önemlidir. Bu

toplantılar sayesinde takım üyelerinin her biri diğer üyelerin nelerle uğraĢtığını öğrenme fırsatını

edinirler ve çalıĢacakları iĢleri diğerleriyle paylaĢtıkları için iĢlerine daha iyi konsantre olabilirler.

Her Sprint'in bitiminde ortaya konulan ürün hakkında geri besleme alabilmek için yazılımla alakalı her

türlü kiĢiye (Ürün sahibi, pazarlama, diğer takımlar vs.) açık Sprint gözden geçirme toplantısı yapılır.

Bu toplantının amacı yazılımın ürün sahibinin gereksinimlerine uygun olarak geliĢtirildiğinden emin

olmaktır. Bu sayede müĢterinin gereksinimleri bir Ģekilde yanlıĢ anlaĢılmıĢ ise bu farkedilir ve bir sonraki

Sprint'de bu hataların önüne geçilir.

SCRUM PLANLAMASı

Bu adımlar ürün sahibinin ürün gereksinim dökümanına yazdığı, zaman içinde geliĢtirip, değiĢtirdiği

gereksinimler bitene kadar tekrarlanır.

Scrum'un projelerdeki baĢarı oranlarını ve kiĢisel olarak verimliliğinizi arttırdığı gözlemlenmiĢtir.

TEKRARLANAN YAZILIM GELĠġTĠRME METODU

Tekrarlanan yazılım geliştirme metodu, yazılım projelerinin sıralı yinelemelerle oluĢturulduğu bir

yazılım geliĢtirme metodolojisidir. Tekrarlanan yazılım metodolojilerinde yazılım projeleri kendi içerisinde

parçalara bölünerek ele alınır. Bu metodolojilerde, oluĢturulan her bir parça kendi içinde küçük bir proje

gibi düĢünülebilir. Asıl proje hedefi, bu küçük projelerin birbirine eklenmesiyle elde edilmektedir.


Tekrarlanan yazılım geliĢtirme metodundaki her bir yineleme kendi içinde bir yazılım projesinin

gereksinim analizi, dizayn, kodlama ve test gibi adımlarını bünyesinde bulundurur. Ancak, her bir

yinelemenin içerisindeki bu proje adımlarının ağırlığı değişkendir. Öyle ki, ilk yinelemelerde gereksinim

analizi kodlamaya göre daha yoğunken ileriki yinelemelerde durum değiĢerek gereksinim analizinin

içeriği küçülmekte ve kodlamanın ağırlığı artmaktadır.


AraĢtırmalar göstermektedir ki, yazılım projeleri büyüdükçe karmaĢıklıkları artmakta ve projelerin

baĢarılı olma oranları azalmaktadır. Diğer yandan projeleri parçalara ayıran tekrarlanan yazılım

geliĢtirme metodolojileri, projelerin karmaĢıklığını ve riski azaltmakta, verimliliği ve baĢarı oranlarını

arttırmaktadır.

Tekrarlanan yazılım geliĢtirme metodunda projenin küçük parçalara ayrılmasının yanında, bu

yinelemeler arasındaki geri bildirimler de büyük önem taĢımaktadır. Geri bildirimler, proje geliĢim

sürecinin esnekliğini ve proje baĢarısını arttırmaktadır. Projeyle hedeflenen sonucun tam olarak

anlaĢılması ve elde edilebilmesi için geri bildirimler oldukça kritiktir.


Özetleyecek olursak, tekrarlanan yazılım geliĢtirme metodu:

Ana projeyi parçalara bölerek karmaĢıklığı azaltmakta,

Bünyesinde bulundurduğu geri bildirimler sayesinde değiĢimi desteklemekte,

Riskleri azaltmakta,

Projelerin baĢarı oranını arttırmaktadır.

ĠĢte bu yüzden, artık tüm dünyada birçok yazılım projesi bu yöntem ile geliĢtirilmektedir.

KAYNAKLAR

http://agilemanifesto.org/

http://www.pragprog.com/titles/pad/practices-of-an-agile-developer

http://en.wikipedia.org/wiki/Agile_software_development

http://www.ibm.com/developerworks/rational/library/08/0701_ellingsworth/

http://scrum-master.com/en/default.aspx

http://www.scrumalliance.org/

agi̇le yöntemleri̇

Business