Yazılım geliştirme de hala en etkili unsur bizzat onu geliştiren insanlar olmaya devam etmekte.Süreçler, iyi pratikler ve araçlar ikinci dereceden etki eden unsurlar: ikinci dereceden olmaları önemsiz oldukları anlamını taşımıyor tabiki ancak bu unsurların hepsi onları kullanan insanlarla bir anlam kazanmakta.Bu çoğu kişi tarafından tekrarlanan ama gerçek anlamı anlaşılmayan bir tespit.
Bunun yanı sıra, bu süreçte karşılaşılaşılan problemlere "hazır raftan alınma çözümler" arama yaklaşımı baskın.Öyle hazır çözümler yok malesef.Elimizi kirletip bu problemleri çözmemiz gerekiyor. "En İyi Pratikler" (Best Practices) diye bir şeyde yok. Sadece belirli bir durumda ve bağlamda işe yarayan "iyi partikler" var. Ne zaman, nerede hangi pratikleri uygulayacağınızı bilebilmek için bu pratiklerin sınırlarını, varsayımlarını içinde bulunan duruma göre iyi tahlil etmeniz gerekir.
Son günlerde özellikle Scrum'la ilgili çeşitli yerlerden gelen "ilginç" yakınmalar arttı. Scrum uygulayan bazı takımlar ilk bir kaç iterasyonda (sprint) hızlı ve müşterinin hoşuna giden çıktılar üretmesine karşın bu takımların daha sonra kararlı bir yazılım mimarisinin oturtulamaması nedeniyle ciddi problemler yaşadıklarını rapor ediyorlar.Bu durum ilerleyen iterasyonlarda takımın hızını azaltıyor (entropinin artması nedeniyle koda eklenen bir özellik veya düzeltilen bir hata başka yerlerin bozulmasına yol açmakta, basit özelliklerin bile sisteme eklenmesi beklenen de çok daha fazla zaman almakta).Kırılgan bir sistemle karşı karşıya kalan takımlar Scrum, teknik pratiklerden yoksun bu nedenle XP hem yönetim ham teknik pratikleri içerdiğinden daha iyi demeye başladı. XP ve pratikleri yeniden "parlamaya" başladı.
Temelde aslında bu türden raporlar Scrum'ın işe yaradığını gösteriyor. Scrum yazılım geliştirmeyi deneysel bir süreç olarak görüyor. Basitce kendisini sürecinizde aksayan unsurları "görünür" hale getirilmesini kolaylaştıran bir süreç meta modeli / çatısı olarak tanımlıyor.Scrum doğru uygulandığında bunları göstermekte başarılı.Ama görünür hale gelen problemleri çözmek bizim işimiz.Scrum bizim yerimize bir şey çözmüyecek.Bu kadar basit aslında.
Scrum XP pratiklerinin kullanılması ya da başka pratiklerin kullanılması konusunda "sessiz" kalan bir süreç meta-modeli/çatısı.Bizzat Scrum takımın ilgili problemleri tespit etmesi, buna yönelik çözümler geliştirmesi, ilgili durumu tahlil ederek kullanılacak pratikleri , araçları belirlemesi gerekiyor.Öğrenen ve kendi kendini düzenleyen bir takım oluşturulmasını vurguluyor. Yine hepsi bu kadar basit ve yalın.[ Ama uygulaması o kadar basit değil tabiki :-) ]
Scrum ve XP birbirini tamamlayacak şekilde kullanılabilir ayrıca.
Kendi adına düşünmeyen takımlar XP'nin "Best Practices" adı altında sunulan Pratiklerinide yanlış bir şekilde kullanacaklardır.Muhtemelen belirli bir süre sonra XP "Gereksinimlerin" belirlenmesi konusunda çok zayıf teknikler sunuyor denilip XP'ye de burun kıvıracaklardır.:-)
Eğer detaylı, yemek tarifi gibi bir süreç adımı istiyorsanız UP 'a / RUP 'a bakabilirsiniz. Fakat onu bile aynen, körü körüne uygulamaya kalkarsanız eczaneye girip tüm ilaçları içen bir müşteri gibi ölebilirsiniz. Nasıl eczaneden doktorun yazdığı bizim ihtiyacımız olan ilaçları alıyorsak, UP uygulayan bir projede de belirli bir probleminize ve ihtiyacınıza çözüm olacak, pratik faydası yüksek az sayıdaki ürünler / çıktılar (artifacts) kümesi üzerinde odaklanmanız gerekir. İhtiyacınız yokken eczanedeki her ilacı içmeye kalkarsanız ölürsünüz! Dikkat etmeseniz UP’de (veya başka herhangi bir süreçte) projenizi öldürebilir!Çünkü Süreçler hazır elbiseler gibi değillerdir! Üzerinize hemen giyemezsiniz! Kendi şirketinizin çalışma kültürüne, sürecin uygulanacağı projenin niteliğine bağlı olarak süreci kendinize göre özelleştirmeniz gerekmektedir.( Elbisenin bazı yerleri bol bazı yerleri uzun gelecektir-UP’nin bazı unsurlarını belki kullanmayacaksınız-, farlı mekânlarda farklı elbiseler giymeniz gerekecektir- Farklı projeler tipleri için farklı UP uyarlamalarınız olacak-, vücudunuza ve elbisenizi giyeceğiniz ortama göre gerekli terzilik işlemlerinizi yapmanız gerekmektedir).
Açıkçası bunları görecek kadar da zeki olmanız gerekiyor.UP bu konuda ilginç bir örnek sunuyor.Zeki ellerde kullanıldığında başarılı sonuçlar vermekte, ama çoğunlukla "körü körüne" uygulandığından çoğu projede başarısızlığın nedeni olarak suçlanmakta.Ve bu nedenle genel olarak UP ağır hantal kağıt/belge odaklı bir süreç olarak algılanıyor. [ bunu haketmediğ halde]
[ Bakınız : Ivar Jacaopson Yes, RUP is my baby. ]
[ Bakınız : Craig Larman,Philippe Kruchten,Kurt Bittner, How to Fail with the Rational Unified Process. ]
Scrum ya da XP yada Çevik (Agile) yada UP etiketi altında sunulan herşeyin tek başına bir önemi yok.Bu tür meta modelleri/çatıları/yöntemleri uygularken aklınızı/zekanızı/sağduyunuzu/deneyiminizi bir tarafa bırakmayın ve kendinizi küçümsemeyin.
En önemli unsur hangi durumlarda/şartlarda, hangi pratikler işe yarayabiliyor, bunların maliyeti, sınırları, varsayımları neler sorularına yanıt verebilmektir.Sizi esas çevik yapacak unsur budur.
Gerek Scrum gerekse XP'yi oluşturan kişilerin kitaplara aktardıkları sadece onların kendi deneyimlere dayanarak oluşturdukları modeller.Kitaplarına, kurslarına algıladıkları biçimiyle ancak "gerçeğin" basitleştirilmiş halini aktarabilirler.[ Harita arazinin kendisi değildir].1-1 ölçeğindeki bir harita ne kadar işe yarar ise bu kişiler gerçekten deneyimlerinin hepsini aktabilselerdi oluşacak modelde o kadar yararlı olurdu zaten.
Yine bu kişilerin "deneyimleri" ile sizin deneyimlerinizin bağdaşmaması da mümkün.Temel problem çözme yetenelerinize güvenin ve onları geliştirin.
Gerçekten çevik bir süreci uygulamaya başladığınızda [yolculuğunuza da ister Scrum ile başlayın ister XP veya diğer] zamanla ortaya çıkacak süreç ana hatları ile "tespit et, manevra yap, adapte ol" ruhunu kaybetmemeiş ama ne tam anlamıyla Scrum ne tam anlamıyla XP süreci olacaktır. [ Her ne kadar bunun yanlış olduğunu söyleyen çok fazla "çevikçi" olsada :-)]. Bu sizin ilgili organizasyon kültüründe, mevcut duruma uyarlanmış size "özel" bir süreç olacaktır.Çünkü sizin deneyimlerinizle başkalarınınkinin "bire bir aynı" olması mümkün değildir.
Süreçlerinizin işe yarar olup olmadığını tespit eden turnusol kağıtlarınız, ve süreçlerinizdeki problemleri görünür hale getiren pratikleriniz olduğu sürece ve bunları çözmeye gerçekten istekli olduğunuz müddetçe ortaya kendi "süreç" meta modeliniz / çatınız çıkacaktır.
Ama dikkat!Süreçlerinizin işe yarar olup olmadığını tespit eden turnusol kağıtlarınız, ve süreçlerinizdeki problemleri görünür hale getiren pratikleriniz yoksa ve bunları çözmeye gerçekten istekli değilseniz ortaya çıkartabileceğiniz şey tek şey size özgü "saçmalıklarla", "korkularla","iş çıkartmaktan ziyade anlamsız politik yapılara dönmüş süreç adımlarıyla" dolu olacaktır.
Sosyal hayattan bir örnek verirsek Türkiye'deki Demokrasi'nin macerası böyle bir seyir izlemiştir. Önce demokrasiyi hazır bir malzeme gibi "raftan" kulanmaya kalktık,sonra bu hazır demokrasiyle işler yürümüyor dedik, sonra demokrasinin hazır bir şekilde uygulanamayacağını farkettik [bir başka ülkenin demokrasi macerasıyla bizimkinin birebir örtüşmesi mümkün değildir] ve daha sonra onu kendi şartlarımıza uyarlamaya değil uydurmaya çalıştık...Ama bu özelleştirmede işin temel ruhunu gösteren turnusol kağıtları kulanmadığımızdan, problemleri görünür hale getiren mekanizmaları devreye sokmadığımızdan ve aslında değişmek gibi ciddi bir niyetimiz olmadığından ortaya sadece bizim "demokrasi" dediğimiz bir ucube çıktı.
Çevik olmak "zeki" olmakla mümkündür."Zeki" olmak da çok zor değil: Herkes doğuştan zekidir.:-).Yeterki onu çeşitli saçmalıklarla köreltmeyin.Bir de işinize "eğlence" "zevk" katın.Gerisi kendiliğinden gelir.
Hamiş: Aşağıdaki Linkler İlginizi Çekebilir: