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. Ben kişisel olarak projelerin gidişatına ciddi etkilerde bulunan
sorunların kaynağının geleneksel yazılım geliştirme süreçleri olduğunu
düşünüyorum. İşte bu yazımda başlıktan da anlaşılabileceği gibi yazılım
geliştirme süreçlerinden kaynaklanan sorunlara çözüm olarak üretilen Agile
Yazılım Geliştirme'den ve Scrum'dan kısaca bahsedeceğim.
Projelerde
karşılaştığım sorunlardan konumuza uygun olanları şu şekilde sıralayabilirim;
ü
Teknolojinin çok hızlı gelişmesi ve bu yeniliklerin projeye 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 (bir
yazılım geliştirme sürecinde 102 ayrı role'un olduğunu duymuştum)
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 aşağıdaki
manifestoyu ortaya koyuyorlar;
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
• 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
(daha fazla bilgi
için agilemanifesto.org)
Manifestonun açıkca belirtiğ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 üretmek (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 çünkü Agile yazılım geliştirme sadece bunlardan
daha önemli kavramların olduğunu vurguluyor). "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.
Scrum'u Agile yazılım geliştirme metodunun yukarıda bahsettiğimiz
presiplerine uygun olarak geliştirilmiş ve tasarlanmış bir metod olarak
tanımlayabiliriz. (Diğer metodlardan XP ve Lean Software Development hakkında
detaylı bilgilere buradan ve buradan ulaşabilirsiniz). Scrum diğer agile yöntemleri
gibi çok fazla kuralı olmayan, sadece belirli prensipleri olan ve kolayca
projelere uygulanabilecek bir yöntem.
Scrum'un genel akış
şeması;
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 yukarıdaki
şemada geçen kavramları genel bir Scrum planlaması ve akışı içinde adım adım
anlatmaya çalışacağım.
1- Roller (Roles)
· Ürün Sahibi (Product Owner)
· Scrum Yöneticisi (Scrum Master)
· Takım Üyesi (Team Member)
2- Toplantılar
(Meetings)
· Sprint Planlama (Sprint Planning)
· Sprint gözden geçirme (Sprint Review)
· Günlük Scrum toplantısı (Daily Scrum)
3- Kavramlar
(Artifacts)
· Ürün gereksinim dökümanı (Product
Backlog)
· Sprint dökümanı (Sprint Backlog)
· Sprint kalan zaman grafiği (Burndown
Chart)
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.
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 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.
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'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?
bu toplatılara
herkesin zamanında ve davet edilmeden katılması ve uzun sürmemesi çok
önemlidir. Bu toplatı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.
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.
Umarım burada
anlattıklarım Agile ve Scrum hakkında bir fikir sahibi olmanızı sağlamıştır.
Özellikle Scrum'un projelerinizdeki başarı oranlarını ve kişisel olarak
verimliliğinizi arttıracağına inanıyorum. Scrum ve Agile ilgili deneyimlerinizi
ve sorularınızı paylaşabilirseniz sevinirim.
Scrum ile ilgili daha
detaylı bilgilere aşağıdaki linklerden ulaşabilirsiniz.
Kaynaklar:
Hiç yorum yok:
Yorum Gönder