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.
Hiç yorum yok:
Yorum Gönder