Çevik Yöntemler ve Teknik Mükemmellik

Önceki yazılarımızda çevik yöntemlerde roller (İlgili Makaleler: Roller, Rollere Uygun Profiller, Liderlik), çevik yöntemlere geçiş (İlgili Makaleler: Dönüşüm, Uygulayabilmek) ve diğer önemli başlıklara (İlgili Makaleler: Başarının Anahtarları, Toplantılar, Güven, Analiz, Test Yönetimi) temas etmiştik. Çevik yöntemlere geçen birçok ekip öncelikle rollere, proje yönetim prensiplerine, toplantılara, dokümanlara ve iş listelerine odaklanıyor. Roller benimsenip, proje yapıları ve toplantı rutinleri oturunca, dokümanlar sadeleştirilip iş listeleri de işler hale geldiğinde çevik dönüşümün tamamlandığı gibi bir yanılsama ortaya çıkıyor. Eğer bir de bu adımlar üretim hızını artırırsa çevik dönüşümle istenen sonucun alındığı düşünülüyor. Üretim hızı kadar yapılan işin teknik yönden sağlam ve aynı zamanda esnek olması gereklliliği genelde göz ardı ediliyor. Sağlamlığı ve esnekliği de bünyesinde barındıran “Teknik Mükemmellik” kavramı hak ettiği yeri alamıyor. Bu yazımızda Çevik Manifesto’nun ardındanki 12 prensipten biri olan Teknik Mükemmellik başlığını ele alacağız.

Bu prensip çevik manifestoda tam olarak şu şekilde ifade ediliyor: “Continuous attention to technical excellence and good design enhances agility”, türkçesi “Teknik mükemmellik ve iyi tasarım konusundaki sürekli özen/dikkat çevikliği artırır.” Bu prensibi sondan başa doğru ele almakta yarar görüyorum. Öncelikle sürekli özene değinmek istiyorum. Hepimizin bildiği üzere çevik dünyada hep bir adım ileri gitme ve gelişimi sürekli kılma ön planda yer alıyor. Hatta bu gelişimi takımın kendi dinamikleri içinde başarabilmesi bekleniyor. Retrospektiflerin (İlgili Makale: Retrospektif) amacı tam da  bu gelişimi devamlı kılmak, hep bir adım ileriye gidebilmek. Tüm başlıklarda olduğu gibi tasarım ve teknik çerçevedeki ilerleme konusundaki sürekli özen de teşvik ediliyor. Hep daha iyisinin olabileceği düşünülüyor, hep bir adım ötesi hedefleniyor.

Teknik Mükemmellik kavramı ile genelde iyi tasarım birbiriyle özdeşleştiriliyor. İyi tasarım bu prensipteki hedeflerden bir tanesi. Bununla birlikte prensipte Teknik Mükemmellik özellikle ve ilk başta ifade ediliyor. İyi tasarım, Teknik Mükemmellik için gerekli ama tek başına yeterli değil. Çok iyi bir tasarım yaptıktan sonra bunu nasıl gerçekleştirdiğiniz ve nasıl test ettiğiniz de bir o kadar önemli. Tasarımı hayata geçirirken hangi alt parçalara ayırdığınız, bu parçaları hangi sıra ile ele aldığınız, aralarındaki bağımlılıkları nasıl yönettiğiniz,  her birini nasıl gerçekleştirdiğiniz, birim testini nasıl yaptığınız, nasıl entegre ettiğiniz, oluşan son ürünü nasıl kontrol ettiğiniz; bütün bunlar üretilen son çıktının kalitesine etki edecektir ve dolayısıyla Teknik Mükemmellik konusudur. Son ürünün kalitesini artıracak, sağlamlık ve esneklik getirecek tüm aksiyonlar Teknik Mükemmellik içinde değerlendirilebilir.

Teknik Mükemmellik için önemli bir adımı da ölçme ve değerlendirme oluşturuyor. Çevik dünyaya yolculuğa çıkarken teknik olarak kurumun bulunduğu durumun fotoğrafını çekmek, hangi noktalarda zayıflıklar olduğunu tespit etmek ve öncelikle bunlara odaklanmak önem taşıyor. Ayrıca çevik yöntemlerle ilerlerken teknik yönden gelişimin izlenmesi ve hedeften ne kadar uzakta olunduğunun tespit edilmesi de gerekiyor. Teknik seviyenin belirlenmesini metrik ölçümlere dayandırmak ve subjektif değerlendirmelere engel olmak da gelişimin daha şeffaf izlenebilmesini sağlıyor. Bu sayede doğru değerlendirmeler yapmak ve isabetli adımlar atarak Teknik Mükemmelik yolunda gelişimi sürdürmek mümkün olabiliyor.

Çevik dünyada teknik pratikler ve iyi uygulamalar söz konusu olduğunda eXtreme Programming (İlgili Makale: XP) ve Test Güdümlü Geliştirme  (İlgili Makale: TDD) gibi teknik yaklaşımlar ön plana çıkıyor. Bunların Teknik Mükemmeliyete önemli katkıları olduğu şüphe götürmez. Bunların dışında kurumunuza özgü ihtiyaçlar için farklı yaklaşımların da benimsenmesi mümkün. Hangi yaklaşım benimsenirse benimsensin önemli olan onu takımların özümsemesini sağlamak ve kalıcı hale getirebilmek. Dahası sürekli özenle Teknik Mükemmelliği ön planda tutabilmek. Unutmamak gerekiyor ki, çevik yöntemler bürokrasiyi azaltıp, işleri daha kolay yapabilmek için zemin hazırlarken, takımlardan daha kararlı ve daha kaliteli ürünler bekliyor.

Çevik Yöntemlere Yolculuk

Proje Yönetim Dünyası Dergisi'nin Ağustos sayısında yayınlanan yazımı altta sizlerle paylaşıyorum. 

Son yıllarda çokça duyulan ve popüler olan yaklaşımlardan biri de çevik yöntemler (agile methodologies). Çevik yöntemler aslında ihtiyaçtan ortaya çıkıyor. Büyük harcamalara rağmen istenen sonucun alınamadığı; bürokrasinin ve hiyerarişinin işleri yavaşlattığı; müşterinin yeterince önemsenmediği; ciltlerle dokümantasyona rağmen son ürünün çalışmadığı projeler bu ihtiyacı doğuruyor. Kökleri 1950'lere dayanan bu yaklaşım 1960'larda 1-2 haftalık iterasyonlar ve kısmi çözümlerle hızlı sonuçlar alınması şeklinde uygulanmaya başlıyor. 1980'lerde Hirotaka Takeuchi ve Ikujiro Nonaka isimli iki Japon bilim insanı yayınladıkları makale ile Scrum yönteminin temelini atıyorlar. Burada rugby oyunundaki toplu hücum toplu savunma anlayışından esinlenilerek takım olarak tüm işin sahiplenilmesi ve yapılması temel felsefeyi oluşturuyor. 1990'larda XP (eXtreme Programming), DSDM (Dynamic Systems Development Method), Scrum, FDD (Feature Driven Development), Crystal, LSD (Lean Software Development), Kanban ve benzeri yöntemler ortaya çıkarak çeşitli projelerde kullanılmaya başlıyorlar. Her ne kadar isimleri ve detayları farklı olsa da temel prensipleri aynı olan bu yöntemlerin temsilcisi 17 kişi, 2001 yılında bir araya gelerek ünlü Çevik Manifesto ile ortak paydalarını ilan ediyorlar. Çevik Manifesto özetle:

• süreçler ve araçlardan ziyade bireyler ve etkileşimlere 
• kapsamlı dökümantasyondan ziyade çalışan yazılıma 
• sözleşme ve pazarlıklarından ziyade müşteri ile işbirliğine 
• bir plana bağlı kalmaktan ziyade değişime karşılık vermeye 

değer verilmesini salık veriyor. 

Çevik yöntemler yazılım ve bilişim projelerinde özellikle 2000’li yıllarla birlikte dünya genelinde oldukça yaygınlaşıyor. Ülkemizde de yaygınlaşma ivmesi 2010’dan sonra gözle görünür biçimde artıyor. Birçok büyük kurum ve kuruluş çevik yöntemlere geçişi başlattı veya planlıyor. Her ne kadar yazılım projelerinde yaygın olsa da çevik yaklaşımlar ve sağladığı yararlar aslında tüm ürünlere ve projelere uyarlanabilir. Bu sebeple çevik yöntemlere yolculuğu da geniş perspektiften ele alıyoruz.

Çevik yöntemlere yolculuk esas itibariyle işe, ekibe ve müşteriye bakış açısını değiştirmeyi gerektiriyor. İşi, ürün perspektifinden ve bütünsel ele almayı, kısa aralıklarla yeni kabiliyetler eklemeyi ve çalışan ürünü temel başarı göstergesi olarak görmeyi gerektiriyor. Ekibi takıma dönüştürmeyi, takıma güvenmeyi, takımın kendini organize edebilmesini, hiyerarşinin ortadan kalkmasını, kollektif sahiplenmeyi ve sorumluluğu gerektiyor. Müşterinin masanın karşısından kalkıp proje takımının yanına oturmasını, proje çalışmalarına dahil olmasını, geri bildirimlerini hemen verebilmesini, değişiklik taleplerini proje boyunca iletebilmesini mümkün kılıyor. Bu paradigma değişikliklerini üst yönetime, müşteriye ve tüm proje paydaşlarına benimsetmek çevik yöntemlerle sağlanacak başarının anahtarı oluyor. 

Çevik yöntemlerle birlikte projeye bakış açısının da değişmesi gerekiyor. Birçoğumuzun bildiği proje başarı üçgeninde köşelerde takvim, maliyet ve kapsamın olduğu; ortada kalitenin yer aldığı varsayılıyor. Takvim, maliyet ve kapsamın plana uygun gerçekleşmesinin projenin temel başarı kriterleri olduğu belirtiliyor. Gerçek hayatta ise genellikle hedeflenen kapsama erişebilmek için takvimin ve maliyetin aşıldığı, kaliteden de çoğu zaman tavizler verildiği bulgulanıyor. Bu gerçeklik karşısında çevik yöntemler, kapsamın serbest bırakılmasını, takvim ve maliyetin sabit olmasını, kaliteden ise taviz verilmemesini tercih ediyor. Elbette kapsamın serbest bırakılması kontrolsüz gerçekleşmiyor. Bilakis kapsam yönetimi Ürün İş Listesi (Product Backlog) ile yakından takip ediliyor, projedeki tüm gereksinimler bu listeye ekleniyor. Listedeki öncelikli gereksinimleri yapmak ve proje tamamlandığı noktada geriye önceliği düşük işlerin kalması temel yaklaşımı oluşturuyor. Müşterinin, Ürün İş Listesi’ne proje boyunca yeni gereksinimlerini eklemesine izin veriliyor. Bu sayede kapsam değişikliklerine fırsat tanınıyor. Gereksinimlerin önceliğini de müşteri belirliyor ve istediği noktada değiştirebiliyor. Bunun tek istisnası proje takımının üzerinde çalıştığı iş paketleri, bunlara dokunamıyor. Proje bittiği noktada, Ürün İş Listesi içinde kalan gereksinimler müşteri tarafından önceliği diğerlerine düşük olarak belirlendiği için, müşteri nezdinde de soruna yol açmıyor.

Çevik yöntemlere geçişle birlikte takımların çalışma prensipleri de değişiyor. Öncelikle takımın projeye dedike olması, başka iş ve projelerde görevlendirilmemesi gerekiyor. Burada temel gerekçe insanın bir tek konuya odaklandığında daha kaliteli ve hızlı üretebilmesi. Bunun arkasındaki sebep de insanoğlunun çoklu düşünme kabiliyetine sahip olmaması, aynı anda çok şeyi düşündüğümüzü sandığımız anlarda bile beynimizin düşünceleri teker teker ancak aralarında çok kısa aralıklar bırakarak işleme aldığı, bunun bize aynı anda çok şeyi düşünüyormuş yanılgısı yarattığı gerçeği.

Takımla ilgili ikinci önemli konu, aynı yerde birlikte çalışma, yüzyüze iletişim kurma şeklinde karşımıza çıkıyor. Mümkünse proje için ayrılmış bir odada, Takım Odası’nda tüm takımın birlikte çalışması, ekibin takıma dönüşebilmesi için büyük önem taşıyor. Takım Odası’nda projeye, ürüne ve gereksinimlere ait durumların rahat izlenebilmesi için duvarlara birşeyler asılması da ürüne odaklanmaya önemli katkı sağlıyor. Takım Odası’nda müşteri tarafından karar verebilecek bir kişinin de takımla çalışması ayrıca katkı sağlıyor. Bunun yapılamadığı durumlarda en azından müşteri ile sık aralıklarla bir araya gelmek ve yapılan çalışmaların gösterilmesini sağlamak yarar sağlıyor.

Takımla ilgili üçüncü konu işlerin planlanmasındaki ve paylaşılmasındaki değişiklik olarak kendini gösteriyor. Çalışmaları artırımlı iterasyonlar olarak planlamak, iterasyonlar sonunda müşteriye değerli ve çalışan bir teslimat sunmak hedefleniyor. İterasyonlarda kabaca nelerin yapılacağı, başta planlansa da tam olarak Ürün İş Listesi’nden hangi gereksinimlerin yapılacağına iterasyon başında takım olarak karar veriliyor. Seçilen gereksinimlerin müşteri tarafından en öncelikli olarak belirlenenlerden oluşması gerekiyor. Bu sayede müşteri için en değerli olan çalışmalara öncelik verilmiş oluyor. Takım üyeleri gereksinimler veya onlarla ilgili alt aktiviteleri kendi üzerlerine alarak paylaşıyorlar. Kimse iş ataması yapmıyor. Bu sayede bireysel sorumluluk ve takım içi güven teşvik ediliyor.

Takımla ilgili dördüncü konu rollerdeki farklılıklar olarak karşımıza çıkıyor. Üç temel rol, Ürün Sahibi (Product Owner), Çevik Proje Yöneticisi (Agile PM), Geliştirme Takımı (Develoment Team) olarak uygulanıyor. Bu rollerin farklı çevik yaklaşımlarda farklı isimleri de olabiliyor. Takım içinde farklı yetkinliklerde insanlar olması teşvik ediliyor. Bununla birlikte takım içinde yönetici veya hiyerarşi taşıyan rollere sıcak bakılmıyor. Bunun takım ruhunu örseleyeceği düşünülüyor.

Yukarıda temel bazı noktalarına değindiğimiz çevik yöntemlere yolculukta, aslında en önemli konu bakış açısını değiştirmek, farklı düşünebilmek. Buna paralel olarak Kuantum Kuramı’nı geliştiren ünlü bilim adamı Max Planck, “bakış açımızı değiştirdiğimiz zaman gördüğümüz şeylerin de değişeceğini” söylüyor. Bakış açısını değiştirmenin ilk ve en temel adımı çevik yöntemlere geçiş için gereken paradigma değişikliğine istekli olunması. Dahası bu yolculuğu sürdürebilmek için azim ve kararlılık gerektiğinin de altını çizmemiz gerekiyor.

Kaynakça:

Adkins L. (2010) Coaching Agile Teams, Addison-Wesley.

Shore J. ve Warden S. (2008) The Art of Agile Development, O’Reilly Press.

Sliger M. ve Broderick S. (2008) The Software Project Manager’s Bridge to Agility, Addison-Wesley.

http://www.yeniprojeyonetimi.blogspot.com