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.
AGĠLE YÖNETĠMĠNĠN GETĠRĠLERĠ
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.
AGĠLE YÖNETĠMĠNĠN GETĠRĠLERĠ
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.
AGĠLE YÖNETĠMĠNĠN GETĠRĠLERĠ
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 YAZILIM GELĠġTĠRME METODU
TEKRARLANAN YAZILIM GELĠġTĠRME METODU
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.
TEKRARLANAN YAZILIM GELĠġTĠRME METODU
TEKRARLANAN YAZILIM GELĠġTĠRME METODU
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.
TEKRARLANAN YAZILIM GELĠġTĠRME METODU
TEKRARLANAN YAZILIM GELĠġTĠRME METODU
Ö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.
TEKRARLANAN YAZILIM GELĠġTĠRME METODU
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/
Recommended