A
B
C
Ç
D
E
F
G
Ğ
H
I
İ
J
K
L
M
N
O
P
R
S
Ş
T
U
Ü
V
Y
Z
Q
W
X
+ İçerik Ekle
Agile, Software, Development
Agile Software Development

Agile Software Development

Merhaba Arkadaşlar,

Geçenlerde bir arkadaşımla yazılımdan nasıl verim alınır ve buna etki eden etkenler üzerine biraz konuştuk. Kendisininde rahatsız olduğu ve sıkıntı çektiği durumlardan bahsetti. Bu sohbetin sonunda bende biraz araştırma gereği duydum, dünya da ve Türkiye"de bunun için neler düşünülmüş neler oluyor biraz inceledim. Ayrıca bir de anket hazırladım. Kısa bir zamanınızı ayırarak ankete katılır ve fikrinizi beyan ederseniz sevinirim. Zira sonuçları ilgili makamlara iletmek adına güzel bir fikrim var.

Bu yazıda birkaç soruna birlikte çözüm bulmaya çalışacağız. Ben kafamdaki soruları yazacağım ve sonrasında yaptığım araştırmalardan derlediğim birkaç şeyi altına ekleyeceğim. Sizlerin bu konudaki düşünceleriniz nasıl ve ne yönde gerçekten merak ediyorum. Makalenin içeriğine anlamlı güzellikler katan karikatürler ise Scott Adams
"a aittir.

Örneğin,

* Ben bir yazılımevi sahibiyim, iyi bir yazılım üreten kaliteli iş çıkaran bir firma olarak tanınmak istiyorum. O zaman çalışanlarımdan en iyi nasıl faydalanabilirim? Bir programcıdan maximum verim nasıl alınır ve  programcının en verimli olduğu saatler nasıl belirlenir?



* Bir yazılım firmasında esnek çalışma saatleri uygulaması sizce çalışanları mutlu eder mi? Bunun ortaya koyulacak yazılıma etkisi ne derece olur? Sonuçlar çalışanların, firmanın ya da her iki tarafın lehine olacak şekilde hangi yönde olumlu eğilim gösterir?
* En iyi kod, işinde fazla tecrübesi olmasa da mutlu olduğu bir çalışma ortamında yazılım üreten bir programcı tarafından mı üretilir yoksa işini iyi bilen tecrübeli fakat yaptığı işi yalnızca para kazanma amaçlı yapan usta programcılar tarafından mı?
* İyi bir program üretmek için yazılımı sevmek yeterli midir?
* İyi bir yazılım iyi bir takım çalışmasından mı yoksa bireysel olarak üretilmiş parça kodların birleşiminden mi ortaya çıkar?

vs...

Şimdi yazılımda verimlilik elde edebilme üzerine yaptığım araştırmaları sizlere sunmak istiyorum.

Yazılımda verimlilik dediğimiz zaman son zamanların moda sözü "agile" hemen karşımıza çıktı. Agile kelime anlamı itibari ile "çevik" anlamına gelmektedir.

Peki yazılıma "Agile Metodolojisi"nin uygulanma fikri nereden gelmişti ve sonuçta neler elde edildi birlikte görelim.



2000 yılı sonlarında Alistair Cockburn, Martin Fowler, Kent Beck, Ward Cunningham, Robert C. Martin gibi yazılım sektörünün önemli isimlerinin oluşturduğu
Agile Software Development grubu
yazılımın atak, çevik ve değişimlere adapte olabilecek (agile) bir biçimde geliştirilmesi gerektiğini ileri sürerek "Manifesto for Agile Software Development" adlı bir çalışma yayınladılar.

Bu grubun ana fikri şu: "Biz şimdiye kadar yazılıma inşaat gözüyle baktık; yazılım projelerini bina yapar gibi yapmaya çalıştık, o yüzden başarılı olamadık. Bu şekilde başarılı olamayız; yazılım inşaat gibi değildir ve yaklaşımımızı temelden değiştirmek lazımdır!"

Bir inşaat projesine baktığınızda işin süreçleri ardışıktır:

Bir bina yapmaya karar verdiğinizde önce binanın gereksinimleri, kullanım ihtiyacı, kat sayısı, inşaat alanı belirlenir. Ardından tasarım başlar. Tasarıma onay verilir ve bina inşa edilmeye başlanır.

Agile metodoloji ise, "Yazılım inşaat gibi değildir; çünkü gereksinimler değişir, tasarımların değişmesi gerekir, kodlama ve gereksinim analizinin iç içe olması gerekir" yaklaşımına ışık tutar ve bize şöyle bir anlamı çağrıştırır:

"Değişim her zaman her alanda vardır. Çalışma yöntemlerinizi değişikliği kabul edecek hale getirin!"...

Yazılım geliştirme sürecinin ilerleyen safhalarında ortaya çıkacak değişim isteklerinin getireceği maliyet nedeniyle, geleneksel yaklaşımlar, başlangıçta yeterince kapsamlı çalışıp ihtiyaçları eksiksiz tespit etmeyi ve bu sayede projenin ileri safhalarında ortaya çıkabilecek olası değişimleri önlemeyi esas alır. Ancak hızlı gelişen teknoloji ve artan rekabet ortamında müşteri gereksinimleri artık daha hızlı değişmekte ve değişim isteklerinin daha çabuk yerine getirilmesi gerekmektedir.

Proje başlangıcında eksiksiz tespit edilmeleri imkansızlaşan müşteri ihtiyaçlarındaki değişimlere engel olunamadığına göre, yazılım projelerinde kullanılacak yazılım geliştirme yöntemlerinin de bu değişimleri daha kısa sürede ve daha az maliyetle karşılayabilecek özelliklere sahip olması beklenmektedir. Bu nedenle, geleneksel yazılım geliştirme yöntemlerine alternatif olarak çevik yazılım geliştirme yöntemleri ortaya çıkmıştır.


Peki agile(çevik) yazılım nasıl olmalı?

Çevik Yazılımın 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,
günlük olarak 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 tam güvenilmelidir.
6- Ekip içerisinde kaliteli bilgi akışı için yüz yüze iletişim önemlidir.


Çevik yaklaşımlar, yazılım geliştirme safhasında geç ortaya çıkan gereksinim değişimlerini çabuk karşılamayı esas alan yöntemlere verilen genel bir isimdir. Bu yöntemlerden adı daha fazla ön plana çıkanlar arasında Scrum, Dynamic Systems Development Methodology (DSDM), Adaptive Software Development (ASD) ve Extreme Programming (XP)’yi sayabiliriz.

Yazılım geliştirmede uygulanan yöntemin başarısı, takip edilen sürece ve kullanılan araçlara bağlı olsa da sonuçta süreci uygulayan ve araçları kullananlar insanlardır. Yetenekli ve usta ekiplerle uygulanan süreçlerin başarısız olma olasılığı düşüktür. Çevik yaklaşımlar, çalışanlara gerekli ortamı ve desteği sağlayarak, başarılı olacaklarına güvenmeyi ve kararlarına değer vermeyi gerektirir.


Çevik Yöntemlerin Yazılım Projelerine Uygunluk Kriterleri nelerdir?

Bir yazılım geliştirme yönteminin her tür projede iyi sonuç vermesi beklenmemelidir. Yazılım projelerinde kullanılacak yazılım geliştirme yöntemini belirlerken projenin özelliklerini dikkate almak gerekir. Projeye uygun olmayan yöntemin kendisi bazen başarısızlık sebebi olabilmektedir. Şu halde, belli metodolojilerin veya süreçlerin
ne zaman ve hangi şartlar altında en iyi çözüm olacağını ve bulunulan duruma göre nasıl biçimlendirileceğini bilmek önemlidir.


Ekibin Büyüklüğü

Yazılı dokümanlardan çok yüzyüze görüşmeye önem veren çevik yöntemlerde çalışanlar arasında iyi iletişim ve etkileşim şarttır. Bu nedenle çevik yöntemlerin uygulanması kararını etkileyen belki de en önemli faktör çalışanların sayısıdır. Çevik yöntemleri deneyen proje ekipleri çoğunlukla 15 kişiyi geçmemektedir.


Ekipteki Ustalık

Proje ekibinin hepsi olmasa bile bir kısmının geçmişte benzer projeler geliştirmiş, kullanılacak teknolojiye hakim ve insan ilişkilerinde iyi özelliklere sahip olması, çevik yöntemlerin uygulanabilirliği için önemlidir. Ekibin organizasyonunda eşli programlama uygulanarak ve proje süresince eşler rotasyonla değiştirilerek, gereken tecrübeli ve yetenekli kişi sayısı azaltılabilir. Ancak bunun için, yardımlaşmayı ve bilgi paylaşmayı seven, alçak gönüllü takım arkadaşlarının önemi büyüktür.


Müşteri Profili

Başlangıçta detaylı gereksinim analizi yapılmadığından, tasarım ve kodlama yapılabilmesi için analizdeki eksikleri doldurmak üzere müşteriyle birlikte çalışmak önemlidir. Müşteri profilinin buna uygun olmaması halinde çevik
yöntemler başarısız olacaktır.


Kritik Uygulamalar

Çevik yöntemlerin; insan hayatını etkileyen sistemler, güvenlik uygulamaları, nükleer sistemler, uzay çalışmaları ve silah sistemleri gibi kritik ve başarısızlık maliyeti yüksek projelerde uygulama örneğine rastlanmamıştır. Kritik sistemlerin geliştirilmesinde tamamen çevik yaklaşımlar kullanmak yerine, geleneksel yöntemlerin içinde, çevik yaklaşımların eşli programlama, önce test kodunu hazırlama ve kademeli geliştirme gibi pratiklerinden faydalanılabilir.


Bakım Safhası

Bazı projelerde bakım safhası, geliştirme safhasından daha önemlidir. Proje teslim edildikten sonraki süreçte geliştirme ekibinde olası değişiklikler ve dokümantasyon eksiklikleri nedeniyle bakım işlemleri maliyeti arttırarak projenin yeniden yapılmasına bile yol açabilmektedir. Çevik yazılım geliştirme yöntemlerinin bakım süreçlerini nasıl etkileyeceği henüz fazla gündeme gelmemektedir. Farklı bir ekip tarafından daha önce çevik yöntemlerle geliştirilmiş bir uygulamanın bakım projesi, uygulama hakkında yeterli bilgi ve belge olmazsa bilinen yazılım mühendisliği sorunlarıyla karşı karşıya kalacaktır.


Çevikliğe Yatkınlık

Çevik yöntemler, yazılım geliştirme teknikleri ve zamanlama gibi teknik konularda karar verme yetkisini üst yönetimden alıp geliştirme ekibinin sorumluluğuna verdiklerinden, kurum içinde bu değişimin benimsenmiş olması gereklidir. Projenin kendisi çevik yöntemlerin uygulanmasına çok elverişli olabilir. Ancak, geliştirme ekibine yeterince serbestlik tanınmayan, ekibin çalışma şekillerinin katı kurallar ve yöntemlerle kısıtlandığı ortamlarda çevik yaklaşımların başarı şansı azalacaktır.


Çevik Metodları farklı kılan esas unsurlar arasında ise aşağıdakiler sıralanabilir:

Whole Team  Planning (Takım Halinde Planlama ):

Çevik  Metodlar, tek başına( örneğin sadece proje yöneticisi)  değil  birlikte yapılan işbirliğine dayalı planlamayı vurgular. Örneğin ilk başlarda yapılacak sürüm planlaması veya  her iterasyon planlaması toplantıları ideal olarak bütün geliştiricilerin  ve müşterilerlerin katılımı ile yapılır. Eğer proje büyük ve alt takımlardan oluşuyorsa, en azından her takımdam bir temsilcinin bu toplantılara katılması sağlanır.

Visible Project Plans ( Herkesçe Ulaşılabilir Görülebilir Proje Planları):

Proje planları (kaba veya detay planlar) -mümkün olduğunca-  tüm takımın kolayca görebilceği şekilde sergilenir( bunun için tahtaları veye basitçe  boş duvar yüzlerini kullanabilirsiniz)


Workers Estimate ( İşi Yapan Kestirimi Yapar ):

Çevik  Metodlar, yapılacak işlere ait tahmini süre/büyüklük kestiriminin bizzat o işi yapacak kişilerce yapılmasını salık verir.


Volunteering (Gönüllülük Esası) :

Çevik Metodlardan olan XP ve Scrum yapılacak görevlerin yönetici tarafından atanması yerine, takım üyelerinin istedikleri görevlere kendilerinin talip olmalarını vurgular.

Yönetmek ve Kontrol etmek yerine takımı destekle ve işlerini kolaylaştır: Yöneticiler için.



Sonuç

Müşteri ihtiyaçlarındaki değişimlerin hızı artmakla birlikte yazılım projelerinden beklentiler de artmaktadır. Hızlı olmak uğruna kaliteden ödün vermemek gerekir. Çevik yöntemlerin iterativ yapısı, projenin erken safhalarında başlayan testler ve onların sonucundaki geri beslemeler sayesinde kaliteli ürün teslimini sağlayabilir görünmektedir. Ancak programcılar ve müşteri haricinde kalite danışmanı veya gözlemcisi gibi kişilere ekipte yer verilmemiş olması bir eksiklik olarak değerlendirilmektedir.

Bir projede en önemli faktör insandır yani yazılım mühendisidir. Metodlar, tasarımlar, mekan vs. gibi etkenler çok önemli olsa da yazılım mühendisi bunların içinde en fazla öneme sahip olandır. O yüzden yazılımcıların motivasyonları kaybedilmemelidir. Ücretleri düzenli verilmeli, kafalarını meşgul eden durumlar ortadan kaldırılmalı ve yazılımcıya kesinlikle güvenilmelidir. Yazılımcıya rahat bir şekilde çalışacağı ortam sağlanmalıdır. Kısacası yazılım mühendisinin, yazılımı düşünmesini etkileyecek etkenler ortadan kaldırılmalıdır.

Bir yazılım ekibi yazılım gereksinimlerinin değişmesine açık olmalıdır.Öyle bir sistem kurmalıdır ki, gerçekleştirilen bir gereksinim değiştiğinde projedeki düzeltilen yerler çok az olmalıdır.Yani proje genişleyebilir ve değiştirilebilir olmalıdır.

Bir yazılım projesi için şu yanlış bir yöntemdir; Müşteri projeyi yazılımcılara devreder ve yazılımcılar proje bitiminde müşteriye yapılanları gösterir. Bu kesinlikle yanlış bir yöntemdir, onun yerine Agile takımlar, müşteri ve diğer kişilerle proje süresince sıkı sıkıya ilişki içerisinde olmalıdırlar.

En önemli unsur yazılımın çalışan kısmıdır. Bir projede yazılım alt yapısı çok iyi kurulmuş olabilir, dökümantasyon çok iyi yapılmış, en önemli kodlar türlü zorluklarla yapılmış olabilir. Her ne kadar bunlar önemli olsada birinci öncelik müşterinin ihtiyaçlarını karşılan, çalışan proje kısmıdır. Bir projede ihtiyaçların %30"u karşılandı ise projenin %30"u bitmiş demektir.

Bir yazılım ekibi kısa mesafe koşucusu gibi bir süre hızlı bir şekilde koşup daha sonra tükenmez.Onun yerine uzun mesafe koşucuları gibi,sürekli sabit hızla gidebilecek kadar hızlı giderler.Hızlı gidip de yorgun düşecekler ise, bu durumda hızlı gitmezler. Hızlı gerçekleştirilen projelerin sonu hiç de iyi olmamaktadır, ilk anda her ne kadar çalışan parçalar elde ediliyor olsada, zaman içerisinde yapılan şeyin aslında ne kadar yanlış olduğu anlaşılmaktadır. Bir yazılım mühendisinin bir sonraki gün ki enerjisi bugünden kesinlikle ama kesinlikle çalınmamalı, yazılım mühendisine bir anda çok yük bindirip, 100 metre koşucusu gibi koşması beklenmemelidir.

Yazılım takımı yazılımı gerçekleştiriken bugünün gereksinimlerine odaklanır ve bugünün problemlerini en basit ve en tutarlı, en kaliteli ve en değiştirilebilir bir biçimde gerçekleştirir. Bugünün işini yaparken yarını düşünerek yapmaz. Yaptığı yazılımlarda kaliteyi en üst düzeyde tuttuğu için yarın karşılacak bir gereksinim sisteme sorunsuz bir biçimde dahil edilebilinecektir(entegre edilebilecektir).

Yazılım ekibi bütün sorumluluklarda ortaktırlar. Yani bir kişi test işinde görevlendirilip, biri veri tabanı işinde görevlendirilip, biri de arayüz tasarlamada görevdirilmez. Bu yanlış bir tutumdur. Takım içiçe olmalı ve herkes her adımda bulunmalıdır. Bazı takım üyelerinin özellikleri bir iş konusunda daha yeterli ise bu durumda belki o kişiye ilgili konuda daha fazla görev verilebilir ama muhakkak diğer takım elemanları da o işe dahil edilirler. Böylelikle bütün problemler yazılım takımının bir elemanı tarafından değil, tamamı tarafından çözülmüş olur.

Yazılım geliştirme projelerinde çevik yaklaşımların yeri, halen devam etmekte olan akademik çalışmaların ve uygulama örneklerinin artmasıyla daha iyi belirlenebilecektir. Dünyada Microsoft, IBM, Google, Yahoo gibi ünlü fimalar tarafından uygulamalar gerçekleştirilmektedir. Türkiye"de ise çevik yaklaşımlarda yazılım ölçüm yöntemleri, yazılım bakımı ve CMMI gibi süreç iyileştirme kriterlerinin sağlanması konularında yapılacak çalışmaların, bu alana katkı sağlayacağı değerlendirilmektedir ve bazı firmalar tarafından uygulanmaya başlamıştır.

Ankete katılmak için tıklayın
.


  Ad Soyad
  Yorum