Agile Yazılım Geliştirme ve Scrum

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-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/

JBoss Seam kitapları ....

Bir önceki yazımda JBoss Seam'in klasik Java Enterprise Development (JEE)'a kazandırdığı çeviklikten, programlama modeline, metodolojisine getirdiği devrim niteliğindeki özelliklerinden bahsetmeye çalıştım. Yeni bir teknoloji öğrenmenin en iyi yolunun o konu hakkında yazılmış kaliteli kitap(lar)ı okumak olduğunu düşünenlerdenim. Bu yazımda da Seam hakkında yazılmış kitapları ve bu kitaplar hakkındaki düşüncelerimi paylaşmaya çalışacağım.


"Seam in Action" Seam'i en kapsamlı şekilde anlatan, okunması rahat ve bol örnekleri olan bir kitap. Manning yayınevinin diğer kitapları gibi bu kitap da oldukça kaliteli ve çok iyi edit edilmiş. Bu kitabı Early Access seviyesinden beri takip ediyorum ve her sayfasından yeni bir şeyler öğrendim diyebilirim. Ayrıca referans kitabı olarak kullanılabilecek şekilde kapsamlı olduğu için başucu kitabı niteliğinde. Fakat kitap Seam'e ilk başlayanlar için biraz ağır gelebilir onun için biraz deneyim kazanıldıktan sonra okunmalı. (5/5)

---

Apress yayınevinden çıkan "Beginning JBoss Seam" özellikle yeni başlayanlar için çok yararlı diyebilirim. Özellikle Seam'in getirdiği yeniliklerden Bijection ve Web Conversation kavramının temellerini başarılı ve kolay anlaşılır bir şekilde anlatıyor.
(4/5)

---

Seam'in 1.x versiyonu sürecindeki geliştiricilerinden Michael Juntao Yuan'ın yazarlığını yaptığı "JBoss Seam: Simplicity and Power Beyond Java" bu kitap yine Seam'e yeni başlayanlar için güzel bir kaynak. Şu anda satışta olan versiyon Seam 1.x sürümünü kapsıyor fakat yakın zamanda Seam 2.x'i kapsayan yeni sürümü yayınlanacak.
(4/5)

---

Apress yayınevinden çıkan diğer bir kitap "Practical JBoss Seam Projects". Henüz bu kitabı okumaya zamanım olmadı fakat okuma listemde üst sıralarda. Okuyan arkadaşlar fikirlerini paylaşabilirlerse çok sevinirim.
(?/5)

---

Seam'in ve Hibernate'in yaratıcısı olan Gavin King'in yazarlığını yaptığı "Java Persistence with Hibernate"'in son ünitesi Seam'e ayrılmış. Seam'in ortaya çıkış sürecini ve temel özelliklerini yaratıcısının kaleminden okumak isteyenler mutlaka göz atmalılar.
(5/5)

Agile Enterprise Java

Enterprise Java programlama ile uğraşmanın en avantajlı yanlarından biri yüksek kaliteli açık kaynak kodlu kütüphane,framework'lerin bulunması. Eminim benim gibi bir çok kişi bu kütüphanelerden yararlanıyordur, artık Hibernate, EclipseLink, iBatis, Spring, Guice, JSF, Struts, Grails, Stripes, ZK, GWT, Wicket, Maven, JUnit vs. olmadan yazılım geliştirmeyi düşününemiyorum. Fakat alternatiflerin çokluğu bazen büyük bir dezavantaja dönüşebiliyor. Bu kütüphaneler arasından geliştirilecek projeye uygun olanları belirlemek ve belirli bir bilgi seviyesine ulaşmak çok kolay bir iş değil. Uygun teknolojileri seçsek bile birbirleriyle uyumlu halde çalıştırmak için çok sayıda konfigurasyon kodu (boilerplate code) ve dosyası yazmamız gerekiyor. Örneğin basit bir Hibernate, Spring, JSF uygulaması yazmak istediğimizde sadece bu üçlüyü bir arada çalıştırmak için yazacağımız konfigurasyon kodları azımsanmayacak derecede çok, ayrıca geliştirme esnasında tekrarlanan kodlar (i.e. faces-config.xml, application-context.xml) sıkıcı olmaya başlıyor ve asıl yoğunlaşmamız gereken programın iş mantığına yeterli zaman ayıramıyoruz.

Bu dezavantajlar son zamanların belki de en popüler konularından biri olan "Agile Software Development" ile tezat oluşturuyordu. Java topluluğunun bu soruna nasıl bir çözüm getireceğini ve Java ile program geliştirenlerin başka programlama platformalarına geçmemesini nasıl engelleyeceğini çok merak ediyordum. Ruby,Rails vb. platformlar topluluktaki ünlü Java Guru'larının bile ilgisini çekiyordu, Craig McClanahan (struts'un yaratıcısı) Java'dan soğuduğunu ve artık Ruby ile ilgileneceği söylüyordu. İşte benim fikrime göre Java bu çıkmazdan iki önemli framework ile çıkış sağladı. Birincisi Hibernate'in yaratıcısı Gavin KING'in fikirlerinden oluşturulan JBoss Seam, diğeri ise Groovy & Grails. Grails ve Groovy üzerine yazmayı sonraya erteleyerek bu yazıda Seam ve getirdiklerini başlıklar halinde kısa kısa anlatmaya çalışacağım.

Enterprise Java programlamayla uğraşan çoğu insanın EJB 2 ve Servlet zamanlarından pek güzel anıları yoktur. Çok sayıda XML konfigurasyon dosyası, EJB 2.0'ları öğrenmenin ve kullanmanın zorluğu, code-compile-deploy-test süresinin uzun ve sıkıcı olması gibi bir sürü sıkıntı. Bu sıkıntıların had safhaya vardığı süreçte ortaya çıkan Spring ve Hibernate vaad ettikleriyle ve başarılarıyla ben de dahil olmak üzere Java ile uğraşanların dikkatini çekti ve çoğu geliştirici kısa sürede Spring,Hibernate ile program geliştirmeye başladı. Spring uzun zamandan beri bilinen Dependency Injection ve Aspet Oriented Programming'e yeni bir bakış açısı getirdi ve Java topluluğunda büyük bir devrim yaptı. Öyle ki Spring ve Hibernate'in bu başarısı örnek alınarak EJB 3.0 standartı çıkartıldı ve EJB ile programlama modeli Plain Old Java Objects (POJO) seviyesine indirgenip EJB ile program geliştirme Spring,Hibernate kadar kolay hale getirildi. Spring 1.x sürümü ve Hibernate çok başarılıydı fakat EJB2.0'da olan sorun burada da vardı; XML karmaşası ve katmanları birbirine bağlamak için yazılan ektra kodlar ve konfigurasyonlar. Bu sorunlar Java 5 ile gelen annotations yardımıyla büyük bir oranda çözüme kavuştu fakat XML dosyaları ve konfigurasyon kodları hala çok fazla emek ve zaman gerektiriyordu.

Spring,Hibernate, EJB3 iş (business) ve veritabanı (database) katmanına kısmi bir çözüm getirdi fakat web arayüzündeki sorunlara uygun çözüm ise hala tam olarak bulunamadı (struts, struts2, Spring MVC, Tapestry, GWT, Grails, Wicket vs.) diyebiliriz. Bu sorunlar için son zamanlardaki en iyi çözümlerden birinin Java Server Faces (JSF) olduğunu düşünüyorum. JSF'nin sorunları ise sadece XML konfigurasyonları ile bitmiyor;
+ Yüksek öğrenme eğrisi (high learning curve)
+ Karmaşık yaşam süreci
+ Bookmark eksikliği, her türlü eylemin HTTP POST üzerinden yapılması vs....
Ama bunların yanında JSF'nin çok iyi düşünülmüş bir yaşam sürecinin olması, toplulukta standart olarak kabul edilmiş olması ve açık kaynak kodlu AJAX kütüphanelerinin olması gibi (icefaces,richfaces) büyük avantajları mevcut.(Açıkcası SEAM olmadan JSF geliştirmek çok can sıkıcı olabiliyor)

JSF for nonbelievers;
1, 2, 3, 4

Enterprise Java'daki Agile Development sorununa çare olmak, JSF ile web geliştirmenin sorunlarını gidermek, Web arayüzü ile İş/Veri katmanı arasındaki sorunları gidermek ve diğer platformlarda olan "Convention over Configuration (Configuration by Exception)" mantığını Java'ya taşımak, Java EE'yi (EJB/POJO/Spring,JSF/GWT/Wicket...,JPA/Hibernate) tek bir çatı altında birleştirmek (unification) üzere geliştirilen JBoss SEAM bence amacını hakkıyla yapıyor. Bütün özelliklerini burada uzun uzun tek bir başlık altında anlatmam imkansız, sadece maddeler halinde SEAM ile neler yapabilabileceğini anlatmaya ve daha detaylı bilgiler alabileceğiniz kaynakları vermeye çalışacağım. Fakat şundan emin olabilirsiniz ki JBoss SEAM ile uğraşmaya başladığınız andan itibaren Enterprise Java ve programlama hakkında bildiklerinizin çoğu şey değişmeye başlayacak ve hiç birşey eskisi gibi olmayacak ....

+ seam-gen; rails ve grails'de bulunan proje oluşturma, nesne ekleme vb. işler için kullanılan komut satırı tabanlı (eclipse entegrasyonu bulunuyor) ant betiği.
+ Configuration by Exception; proje oluşturduğunuz zaman yapmamız gereken konfigurasyonlar yok denecek kadar az. Sadece olağandan farklı bir davranışa ihtiyaç duyduğunuz zaman konfigurasyon yapmamız yeterli oluyor.
+ Bijection; Inversion of Control (IoC) veya Dependency Injection olarak bilinen yöntemin bir üst seviyesi veya dinamik IoC diye adlandırabiliriz. Böylece SEAM nesnelerine sadece bağlı oldukları nesneler verilmekle kalmıyor aynı zamanda SEAM nesneleriyle dinamik olarak SEAM container'ına Seam nesneleri gönderebiliyoruz.
+ Annotations desteği; bu sayede XML kullanımı minimum'a iniyor, tabii ki Seam annotations kullanmayı zorunlu kılmıyor eğer istersek annotations yardımıyla yaptığınız herşeyi XML ile yapabiliyoruz.
+ Aspect Oriented Programming desteği
+ Asenkron haberleşme için Events API'si ve Quartz desteği ("Observer Pattern" uygulayarak nesneleri birbirine daha az bağımlı (loosecoupled) hale getirebiliyoruz)
+ Servlet API'sinde bulunan application, session ve request scope'larına ek olarak Conversation, Page ve Business scopeları.
+ POJO programla modeli; EJB3 veya POJO arasındaki tercih bize kalıyor ayrıca bunlar arasında geçişler çok kolay yapılabiliyor ve EJB3'den POJO programlama modeline geçtiğimizde fonksiyonalite kaybı yaşamıyoruz.
+ Groovy desteği; Seam component'lerini groovy ile yazabiliyoruz
+ Web arayüzünde sadece JSF yerine Wicket, GWT, Tapestry veya Flex kullanabiliyoruz.
+ Rails ve Grails'de kullanılan Active Record'a benzeyen fakat biraz daha farklı olan Home Pattern yardımıyla veri tabanı objelerini yönetebiliyoruz.
+ Çok kolay bir şekilde normal HTML kodu yazarmış gibi PDF, RTF , grafik ve email gibi zengin içerikler oluşturabiliyoruz.
+ Spring ile güçlü entegrasyon; spring ile yazılmış projeler SEAM getirdiği yeniliklerden basit konfigurasyon ile yararlanmaya başlayabiliyor.
+ WebService ve RESTfull URL desteği
+ Basit veya gelişmiş güvenlik ayarları; sayfa, sınıf ve method bazında rol tabanlı güvenlik ayarlamaları yapabiliyoruz
+ jBPM ve Drools desteği
+ Javascript remoting kütüphanesi
+ Sanılanın aksine Seam ile geliştirilen programlar sadece Jboss AS'de çalışmıyor. Piyasada bulunan BEA WebLogic, IBM WebSphere, Oracle Containers for Java EE (OC4J), Apache Tomcat, ve GlassFish gibi sunucularda da sorunsuz şekilde çalışıyor.
+ extended persistence context, declerative transaction management, unified expression language, hibernate validations, page actions, page parameters, bookmarkable links .....

Bunlar Seam'in getirdiği yeniliklerden sadece birkaçı. Bence Seam uzun zamandır Java geliştiricilerinin beklediği bir kütüphane. Seam'i deneyince sizin de bana katılacağınıza ve Seam ile program yazmaktan keyif alacağınıza eminim.

Daha fazla bilgi için;

Seam dökümanları
Seamless JSF Serisi;1, 2, 3
Seam 2.0 hakkında yazılmış en yeni ve iyi kitap;



PS: Bazı teknik terimleri Türkçeye çevirmekten özellikle kaçındım çünkü Türkçe tercümelerin kavramları tam olarak anlatamadığını düşünüyorum.