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
(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:
http://agilemanifesto.org/http://www.pragprog.com/titles/pad/practices-of-an-agile-developerhttp://en.wikipedia.org/wiki/Agile_software_developmenthttp://www.ibm.com/developerworks/rational/library/08/0701_ellingsworth/http://scrum-master.com/en/default.aspxhttp://www.scrumalliance.org/
