Ç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

Çevik Yöntemlere Dönüşüm

Çevik yöntemleri son dönemde sıkça duyuyorsunuz, hatta etrafınızdaki şirketlerden dönüşüm yapanları veya deneyenleri görüyorsunuz. Çevik yöntemlerin kendi kurumunuza da faydalı olacağını düşünüyorsunuz, ancak endişeleriniz var. Aklınızda sorular uçuşuyor:

•  “Dönüşüme nereden başlamalıyım?”
• “Neleri değiştirmeliyim?”
• “Kimleri dahil etmeliyim?”
• “Nasıl yaygınlaştırmalıyım?”
• “Eski alışkanlıklara dönüşü nasıl engellemeliyim? Dönüşümü nasıl kalıcı hale getirebilirim?”
• “Nerede durmalıyım?”
• “Sözde çevik noktasında kalır mıyım?”“Özde çevik olabilecek miyim?”
• “Dönüşümün faydasını ne zaman görürüm?”

Çevik yöntemlere dönüşüm genellikle “hızlı kod yazmaya” başlamak olarak algılanıyor ve IT ekipleri ile sınırlı kalıyor. Özellikle üst yönetim, müşteri ve diğer paydaşlara yeterince anlatılmadığı için yeterince anlaşılamıyor.Dolayısıyla destek alamadığı ve istenen sonuçların ortaya çıkmadığı durumlara çok sık rastlanıyor. Halbuki dönüşüm için müşteri ve üst yönetimin tam desteği olmazsa olmaz. Onlara nelerin nasıl değişeceğini ve sonuçlarının nasıl olacağını anlatmak ve de tam desteklerini almak dönüşümün ilk adımlarından birisi olmalı.

Dönüşümler genellikle kurum çapında geniş katılımlı eğitimlerle başlıyor, eğitimlerde ideal yapılar anlatılıyor. Eğitimden sonra insanlar çevik yaklaşımları beğeniyorlar ancak kendi çalışmalarına nasıl uygulayabileceklerini göremiyorlar. Aradan zaman geçince ve uygulama fırsatı bulamayınca eğitimdeki bilgileri de unutuyorlar.Her ekibin farklı dönüşüm deneyimi oluyor. Kimi tam dönüşemeden iki arada bir derede kalıyor. Yöntemlerini anlatırken de şöyle cümleler kullanıyorlar “çevik ama...”. 

Okuduklarımdan, gözlemlediklerimden ve deneyimlerimden derlediğim birkaç dönüşüm tavsiyesine bu yazıda yer vermek isterim:

• Çevik yöntemlere dönüşümün de bir proje olması ve hatta çevik bir proje olması. Dönüşüm için bir takım kurulması ve yaşayan bir iş listesi (product backlog) oluşturulması.
• Uygulamanın pilot ekiplerle başlatılması ve kademeli olarak yaygınlaştırılması.
• Çevik yöntemlerdeki rollerin iyi anlatılması ve doğru role doğru kişinin getirilmesi (İlgili Makale:Çevik Yöntemlerdeki Rollere Uygun Profiller).
• Planlanan eğitimlerin iki aşamalı olması. İlk aşamada genel çevik yöntemleri içeren bir program, ikinci aşamada ise kurumdaki çevik uygulamanın nasıl olacağının anlatıldığı bir program. Pilot seçilen ekiplerin iki eğitimi de alması ve ardından ekibe dahil edilecek koç ile uygulamanın başlatılması.
•  Farklı takımların deneyimlerini birbiri ile paylaşabilmesi için ortamlar yaratılması.
•  Retrospektiflerin mutlaka etkin yapılması, ekiplerin de gelişim fırsatlarını görmelerinin sağlanması (İlgili Makale:Çevik Yöntemlerde Retrospektif).
•  Tüm ekiplerin çevik yöntemlere geçişinin zorlanmaması. İsteyen, gönüllü olan, müşterileri ve işleri uygun olan takımlardan başlanması süreci kolaylaştırabilir.
• Sabırlı olunması, dönüşümün en az 2 yıla yayılması. Özellikle verimliliğin artması, üretim hızının yükselmesi için acele edilmemesi gerekiyor.
•  Dönüştükten sonra durulmaması, çevik yöntemleri daha etkin kullanabilmenin yollarının araştırılması. Bu noktada Kai-zen felsefesi ve bu felsefede olan “mükemmel yoktur, daha iyisi vardır” yaklaşımı benimsenebilir.

Bunlardan başka  önemli noktalar da muhakkak var. Bence en önemli olan zorlukları görünce pes etmemek, dönüşüme azimle devam etmek ve de gerçekten uygulayabilmek (İlgili Makale:Çevik Yöntemleri Uygulayabilmek).

Savuşturmacı Kültür

Alttaki türden yanıtları sıkça duyuyor musunuz?

• “Bakarız”
• “Sonra yapalım”
•  “Daha zaman var”
• “Daha acil işler var”
•  “Yönetime sormak lazım”
•  “Bu konudan ben sorumlu değilim”
• "Buna ne gerek var”

Bu liste uzayıp gidebilir. Bu yanıtları alınca içinizden ne geçiyor, ne düşünüyosunuz? Karşımızdakinin bir şeyi yapabilecekken yapmadığını, işten kaçındığını veya ötelediğini, değil mi? Hatta bazen karşımızdakinin zamanının olduğunu, yetkisinin uygun olduğunu ve dahası kendi işi olduğunu bilsek bile bu yanıtı alıp şaşırdığımız oluyor. O kadar yaygın ki aile içi ilişkilerde, arkadaşlar arasında bile bu durumlara çok sık rastlanıyor. Esas itibariyle hem iş hayatında hem de günlük hayatımızda çokça karşılaştığımız durumlar bunlar. Literatürde tarayabildiğim kadarıyla bir sınıflamasını bulamadım ve Savuşturmacı Kültür adınının uygun olabileceğini düşündüm. Eğer bir yerde geçiyorsa ve atlamışsam kusura bakmayın ve lütfen beni de bilgilendirin.

Savuşturmacı Kültür’ün iki stratejisinin olduğunu düşünüyorum, ilki yukarıda örneklerini vermeye çalıştığım, “işi yapmama veya öteleme”, ikincisi ise “yapılmış gibi, olmuş gibi, doğruymuş gibi gösterme”. İkinci stratejide işle veya durumla ilgili sorulara gerçek dışı yanıtlar verme, olduğundan farklı ve iyi gösterecek bilgilendirmeler yapma esastır. Bir çalışanınıza işin durumunu sorduğunuzda aldığınız şu tür yanıtlar bu duruma örnek gösterilebilir:

•  “Bitmek üzere”
•  “Sorun yok”
•  “Risk yok
•  “Hallediyoruz”
•  “Yetişir”

Bu güzel bilgilendirmeler sonunda yönetici konumundaysanız içinize su serpilir, rahatlarsınız. Ama işin aslı öyle değildir ve nitekim işin sonunda beklenen sonuç ortaya çıkmaz, sorun olduğu da ancak duvara çarptıktan sonra ortaya çıkar.

 

İşin bitmemesi, gecikmesi veya hatalı olması durumunda da iyi bir bahane bulunması veya günah keçisi tespit edilip tüm sorumluluğun ona yüklenmesi  Savuşturmacı Kültür’ün tamamlayıcı savunma stratejisidir. Hatta çalışma boyunca “işi nasıl iyi ve zamanında yaparım?” sorusu değil “nasıl ikna edici bir bahane bulurum?”, “başarısızlığın sorumluluğunu neye bağlayabilirim?”,“kimi günah keçisi yapabilirim?” türünde sorular da zihinleri meşgul eder. İşin sonunda sorunun kaynağını sorduğunuzda hep başka birisi hatalıdır veya başka bir kurum işini iyi yapmamıştır.

Bir kurumda Savuşturmacı Kültür ne kadar hakimse verimlilik ve etkinlik o kadar düşüktür. Kuruma sonradan katılanlar da ister istemez bu kültürün etki alanına girerler. Kimsenin iş yapmak istemediği, bunu da farklı bahanelerin arkasına saklanarak dolaylı dile getirdiği bir ortam oluşur. Yürüyen işler gereği gibi şeffaf raporlanmaz, tüm işlerin sorunsuz ilerlediği yanılgısı oluşturulur. Bu sorunsuz(!) işlerin sonuçlarındaki başarısızlıklar da hep başka bir etkene bağlanır veya yanlış kişilere fatura kesilir. Başarısızlığın sebeplerinin yanlış teşhis edilmesi sonucu ortaya çıkar ve yanlış tedaviler uygulanır. Bu tedavilerde istenen sonuçlar alınamaz ancak Savuşturmacı Kültür bu noktada da devreye girerek kök sebebe inilmesine izin vermez.

Bir çok kurumda Savuşturmacı Kültür’ün hakimiyeti bulunuyor ve maalesef farkına varılamıyor. Savuşturmacı Kültür’ün panzehirinin alttaki adımlardan geçtiğini düşünüyorum:

• Bahane üretme yerine Sorumluluk Alma: İşin yapılmaması için bahane üreten kişilerin teşvik edilmediği; sorumluluk alarak işleri yapma motivasyonu taşıyan kişilerin ödüllendirildiği bir çalışma ortamının oluşturulması.
• Yanlış raporlamalar ve manipülasyon yerine Şeffaflık: Yanlış, eksik veya yanlı raporlamaların, bilgilendirmelerin kabul edilmediği; sorunların/risklerin tespit edildiği anda şeffaf olarak aktarıldığı durumların kabul gördüğü iletişim ortamının sağlanması.
• Başkasını suçlama yerine Özeleştiri Yapabilme: Hatayı hep dışarıda aramanın, başkalarını suçlamanın uygun bulunmadığı; iğneyi kendine de batırmanın öneminin vurgulandığı özeleştiri alışkanlığının kazandırılması.

Çevik Yöntemlerdeki Rollere Uygun Profiller

Çevik yöntemlerdeki rollerden daha önce bahsetmiştik (İlgili Makale: Çevik Yöntemlerde Roller). Bu rollere uygun profiller neler? Kim hangi role daha uygun? Ürün Sahibi ve Çevik Proje Yöneticisi rollerinin altından kim kalkabilir? Herkes Geliştirme Takımı'nda yer alabilir mi? Bu yazıda bunlara değineceğiz.

• Geliştirme Geliştirme Takımı Üyesi Profili:

• Temel Çevik Yöntem Bilgisi: Çevik yöntemlerin bütün süreçlerini bilmesinde fayda var, ancak uzman seviyesinde olması beklenmiyor.
• İşbirliğine Yatkın ve Uyumlu: Takım içinde birlikte çalışmaya yatkın, takımın kalanı ile uyumlu ve ılımlı geçinebilmesi takımın ahengi için olmazsa olmaz bir özellik.
• Organize: Kendini organize edebilen bir takım kurabilmek için kişilerin de işlerini organize yürütebilmesi ve başkalarının arkalarını toplamasını beklememeleri gerekiyor.
• Pro-aktif: Harekete geçmek için bir sorun/engel oluşmasını beklemeyen veya motivasyon için başkasına ihtiyaç duymayan kişilikte olması gerekiyor.
• Yeterli Teknik Uzmanlık:  Çevik yöntemlerde teknik mükemmeliyet ön planda tutuluyor.  Hem sağlam ve esnek tasarım hem de hızlı üretim için teknik yeterlilik en temel ihtiyaç. Uzmanlık bazen hafife alınan bir kavram ne yazık ki. Bir konuda uzman olabilmek için o konuda yeterli bilgi ve tecrübe sahibi, konuyu farklı yönleriyle incelemiş, alternatifleri bilen, derinlemesine bilgi sahibi bir profilden bahsediyoruz.  Uzmanın sadece yapabilen değil, aynı zamanda en iyisini yapabilen olması gerekiyor.
• Takım oyuncusu: Çevik yöntemlerde bireysel başarıdan ziyade takım başarısı ön planda, tıpkı spor müsabakaları gibi takımın başarılı olmadığı durumlarda bireysel başarıdan da söz etmek mümkün değil. Dolayısıyla iyi takım oyuncusu olan profiller çevik yöntemlere daha yatkın olacaktır.
• Sorumluluk sahibi: Çevik yöntemlerde kimse takım üyelerine iş atamıyor, bilakis kendileri iş listesinden yapabileceklerini seçip sorumlu olduklarını o iterasyonda tamamlamaya çalışıyorlar. Dolayısıyla her takım üyesinin sorumluluk sahibi olması çok önemli.

• Ürün Sahibi Profili:
• Çevik Yöntem Uzmanı: Çevik yöntemleri iyi bilen, hem kendi hem de takımın sorumluluklarına hakim olması çalışmayı ve ürünü doğru yönlendirmede oldukça önemli. Ürün vizyonuna nasıl ulaşılacağını çevik yöntemlerin sağladığı yollarla belirlemesi gerekiyor.
• İş Alanı Uzmanı: İlgili ürünün iş modelini yapısını çok iyi bilmesi, rakipleri tanıması gerekiyor. Müşteriler ile teması olması ve onların hedeflerine de aşina olması elzem.
• İletişim ve Müzakere Becerileri: Hem müşteri hem de geliştirme takımı ile yapacağı görüşmelerde iletişim becerilerine çok ihtiyacı olacaktır. Gerekli noktalarda müzakere yapabilmesi de ihtiyaçlardan bir diğeri. 
• Pro-aktif: Tıpkı geliştirme takımı üyeleri gibi harekete geçmek için bir sorun/engel oluşmasını beklemeyen veya motivasyon için başkasına ihtiyaç duymayan kişilikte olması gerekiyor.
• Karar Verici: Ürünü doğru yönlendirebilmek doğru ve hızlı karar verebilmek bir diğer ihtiyaç duyulan özellik. Karar verirken alternatifleri görebilen ve en faydalıyı seçen bir yaklaşıma ihtiyaç duyuluyor. 
• Pragmatik: Yaptığı çalışmalarda ürünün faydasını ön planda tutan, vizyona katkısını takip eden bir yaklaşıma her zaman ihtiyaç olacaktır.

• Çevik Proje Yöneticisi:
• Çevik Yöntem Uzmanı: Çevik yöntemleri iyi bilen, hem kendi hem de takımın sorumluluklarına hakim olması çalışmayı doğru yönlendirmede oldukça önemli.
• Hizmet Eden Liderlik: Bu çok önemli bir kavram. Klasik yönetim tarzındaki iş ver-takip et (command and control) veya direktif verici liderlik anlayışları çevik yöntemlerde istenmiyor. Bunun yerine koçluk edebilen, takımın önünü açan liderlik anlayışı ön planda tutuluyor. Takımın zaten ne yapması gerektiğini bildiği, yöneticinin detaylara karışmasına gerek olmadığı farz ediliyor.
• Problem Çözme Becerileri: Takım içinde veya takımla paydaşlar arasındaki  iletişim kazalarında devreye girebilmesi bekleniyor. Ayrıca takımın getireceği farklı problemlerde doğru çözüme ulaşılmasını sağlaması gerekiyor. Her problemi çözmesi beklenmiyor, çözümün Takım tarafından bulunmasında katalizör rolü oynaması yeterli olacaktır.
• Motivasyon Verebilen: Motivasyon çok geniş bir kavram, burada beklenti takımın çalışma boyunca motivasyonunu koruyabilmesi için gerekli önlemleri alabilmesi.
• Koçluk Yapabilen: Takıma hizmet eden liderlik çerçevesinde yöneticilikten ziyade koçluk yapması ve takım üyelerinin gelişimini sağlaması oldukça önemli. Koçluk da geniş bir kavram.
• Erişilebilir, Konuşması Kolay: İletişim becerilerinin iyi olmasının yanında, takımın rahatlıkla ulaşabildiği, konuşmaktan çekinmeyeceği bir mizaçta olması çok fayda sağlayacaktır.

Yukarıdakilere farklı özellikler de eklemek mümkün. Öte yandan bu profillerde çalışan bulmak kolay değil; bulunup bir araya getirilince mayanın tutacağının yani takım olunacağının garantisi de bulunmuyor. Bu konuda üst yönetimin desteği ve insan kaynakları politikalarının gözden geçirilmesi ile Takım Olmanın değerli kılınması kuşkusuz çok önemli. Takım olabilmek için de güven sağlanması ilk ve en önemli adım (İlgili Makale: Çevik Yöntemlerde Ekipiçi Güven ve İşbirliği). Kişisel görüşüm bireysel başarıları destekleyen günümüz iş dünyasının zamanla değişeceği ve takım başarılarını ön plana çıkaran yaklaşımların er geç benimseneceği...

Çevik Yöntemlerde Roller

Çevik Yöntemleri farklı boyutları ile daha önce ele almıştık (İlgili Makaleler: Çevik Yöntemleri Uygulayabilmek, Çevik Yöntemlerde İş Analizi, Çevik Yöntemlerde Ekip Liderliği, Çevik Yöntemlerde Test Yönetimi, Çevik Yöntemlerde Ekipiçi Güven ve İşbirliği, Çevik Yöntemlerde Toplantılar). Bu yazıda rollerine değinmek istiyorum. Çevik Yöntemlerle çalışan takımlarda bildiğimiz hiyerarşik ve sorumlulukların çok net ayrıştırıldığı roller bulunmuyor. Bunun yerine daha az sayıda kişiden oluşan ve kendini organize edebilen takımlar kuruluyor. Farklı Çevik Yöntemlerde isimleri farklı olsa da benzer özellikler içeren alttaki temel roller mutlaka yer alıyor:

• Müşteri Temsilcisi veya Ürün Sahibi (Product Owner): Ürünü tarif eden, öncelikleri belirleyen ve yapılanları değerlendiren kişi. Ürün Sahibi'nin özellikleri:
• 1 kişi
• Müşteri ve diğer paydaşlarla iletişim
• 'Ne’ sorusuna odaklı
• İş maddelerinde son karar verici
• Ürün İş Listesi yönetimi ve önceliklendirilmesi
• Ürün vizyonunu belirlenmesi
• İterasyon sonunda ürün ve/veya özelliklik kabulü
• Yapılan işin ekonomikliği (ROI) takibi
• Geliştirme Takımı (Development Team): Farklı becerileri
  olan kişilerden oluşan, yazılımı, entegrasyonu ve birim testi yapabilen takım. Kimseden talimat beklemeden işlerini planlayıp ilerleyebilen, destek gereken noktaları ayırt edip eskale edebilme becerisine sahip. Geliştirme Takımı'nın özellikleri:
• 4-9 kişi
• Belirlenen kalite standartlarına uyulması
• ‘Nasıl’ sorusuna odaklı
• İterasyona alınacak işlerin seçilmesi ve gerçekleştirilmesi
• Kendini organize edebilir
• Farklı yetkinlikler içerebilir
• Çevik Proje Yöneticisi (Agile Project Manager): Takımın önünü açan, işin detaylarını
  yönetmeye çalışmayan lider kişi. Bildiğimiz Proje Yöneticisi işlevlerini yapmıyor. Örneğin zaman, kapsam, takvim ve kalite yönetiminden sorumlu değil. Çevik Proje Yöneticisi'nin özellikleri:
• 1 kişi
• İşlerin kolaylaştırılması
• Takıma gelebilecek dış etkilerin giderilmesi
• Takımın önündeki engellerin kaldırılması
• Müşteri ve diğer paydaşlarla iletişim
• Sürecin doğru işletilmesine odaklı
• Takıma hizmet eden liderlik profili

Yukarıdaki rollere sahip kişiler takım olarak çalıştıkları ve başarı/başarısızlık herkese ait olduğu için klasik ekiplere kıyasla iletişim ve verimlilik anlamında fark yaratabiliyor. Bu fark için Çevik Yöntemler'e üst yönetimin de destek vermesi ve takımın önünü açması tabi ki en önemli koşul. Bir çok yönetici için bu durum çok kolay değil, çünkü ekiplerine talimat vermeleri ve işleri kontrol etmeleri Çevik Yöntemler'de pek de istenmeyen bir durum. Hatta takımların kendi içinde organize olabileceğine birçok yönetici ilk aşamada inanmıyor bile... Üst yönetimin desteğini almak içinse çoğu zaman örnek projelerle Çevik Yöntemler'in çıktılarını somut olarak göstermek en iyi ikna yöntemi oluyor. 

Çevik Yöntemlerde Toplantılar

İş hayatında toplantı yapmamış olan var mı? Bence yoktur, tüm iş ortamlarında kısa, uzun; az, çok; resmi, gayri-resmi toplantılar yapılır. Kimi zaman tüm günümüz toplantılarda geçer. Eğer yapmamız gereken başka işler varsa, toplantıya katıldığımız için keyfimiz kaçar, zaman zaman da toplantıyı düzenleyene içten içe kızarız. Hatta bir kısmımız toplantıların verimsiz ve gereksiz olduğunu düşünür. Kimi zaman da gereksiz ve detay konulara girilerek asıl amaçtan uzaklaşılır. Bazen konu uzar, istenen noktaya ulaşılamaz ve süresini aşar. Bazı rutin toplantılarda ise gündem olmasa bile toplanılır ve pek de bir sonuç alınmadan ayrılınır.

Toplantıyı niye yaparız? Fikirleri paylaşmak, bilgilenmek, bilgilendirmek, ikna etmek, ikna olmak, karar vermek... Bu amaçlara ulaşabilmek için çevik yöntemlerde de toplantı yapılır. Çevik yöntemleri daha önce farklı başlıklarda ele almıştık (İlgili Makaleler: Çevik Yöntemleri Uygulayabilmek, Çevik Yöntemlerde İş Analizi, Çevik Yöntemlerde Ekip Liderliği, Çevik Yöntemlerde Test Yönetimi, Çevik Yöntemlerde Ekipiçi Güven ve İşbirliği). Çevik yöntemlerde çalışmaların etkin olması, gereksiz iş yapılmaması hepimizin bildiği üzere ön plandadır. Toplantılar da aynı prensiplere göre organize edilmiştir: ihtiyaç kadar, belli hedeflere dönük ve zaman sınırlı (time-boxed). Uygulanan çevik yöntemler farklı bile olsalar, temel toplantıları benzerdir ve şöyle özetlenebilir:

• Vizyon Toplantısı: Buradaki amaç, çalışmaya konu ürünle ve projeyle ilgili vizyonun konulması, bu vizyon için gidilmesi gereken yolun ana hatlarının belirlenmesidir.
• Sürüm (Release) Planlama Toplantısı: Sürüm içinde ele alınacak konuların belirlenmesi, önceliklerin değerlendirilmesi amacıyla yapılır.
• İterasyon Planlama Toplantısı: İterasyona başlarken yapılan bu toplantıda, o iterasyonda hangi işlerin, kimler tarafından yapılacağı takım olarak belirlenir. Temelde bu toplantı iki aşamalıdır. İlk bölümde "ne yapılacak" sorusuna karşılık aranır, ikinci bölümde "nasıl yapılacak" sorusuna yanıt verilir. Yarım gün veya tam gün olabilir. Süre baştan belirlenmiş olmalıdır.
• Günlük Ayaküstü (Daily Stand-up) Toplantı: 15 dakika ile sınırlı bu toplantıda, takım üyelerinin her biri kısaca "dün ne yaptım?", "bugün ne yapacağım?", "önümdeki engeller nedir?" sorularını yanıtlar. Toplantı ayaküstü ve sabah ilk iş olarak yapılır.
• İterasyon Gözden Geçirme Toplantısı: İterasyon sonunda tamamlanan çalışmaların demosunun yapılması, Müşteri veya Ürün Sahibi'nin görüşlerinin alınması amacıyla düzenlenir. Kabulü yapılan iş maddeleri kullanıma sunulmak üzere hazırlanır. Kabul edilmeyenler ise Talep Listesi'ne (Product Backlog) iade edilir.
• Retrospektifler: Hem İterasyon sonunda hem de Sürüm sonunda yapılır. Retrospektif başlığını daha önce etraflıca ele almıştık (İlgili Makale: Çevik Yöntemlerde Retrospektif).
• Talep Listesi Sadeleştirme (Product Backlog Refinement): Bu toplantıda Talep Listesi'nin üzerinden geçilerek büyük konular küçük parçalara ayrılır. İhtiyaç kalmayan talepler ayıklanır. 

Farklı çevik yöntemlerde isimler farklı olabilir. Örneğin Scrum'da iterasyonun özel adı Sprint'tir. Sprintler içindeki toplantı akışı yandaki şekilde olduğu gibi döngüseldir. Günlük Scrum Toplantısı, Sprint içinde tekrarlanır ta ki Gözden Geçirme Toplantısı'na kadar.

Tüm bu toplantılara herkes davet edilmez. Kime ihtiyaç varsa onlar davet edilir. Örneğin Retrospektifler, Takım içinde yapılır. Sürüm ve İterasyon Planlama Toplantıları'nda Ürün Sahibi, Çevik Takım olmazsa olmazdır. Çevik Proje Yöneticisi süreci takip etmek amacıyla katılır. Diğer paydaşları ihtiyaç olmadıkça toplantıya dahil etmemek verim için gereklidir. Toplantının zaman ve kapsam yönetimi konularında Çevik Proje Yöneticisi aktif rol oynar. Konuşulan içeriğe ise müdahale etmez. Dolayısıyla gereksiz detaylar ve uzayan toplantıların önüne geçilir. Toplantıların süre sınırlı olması, hedefe dönük olması, ilgisiz katılımcıların davet edilmemiş olması, hem verimi hem de toplantılarla ilgili motivasyonu arttırır.

   

Çevik Yöntemlerde Ekipiçi Güven ve İşbirliği

Çevik yöntemlerin müşteri ve temsilcisi ile teknik ekiplerin bir arada çalışmasını beklediğini hepimiz biliyoruz. Bu temellere göre çevik bir projedesiniz ve ekiple müşteriyi bir araya getirmeyi başardınız. Eskiden kalma ön yargılar sürdüğü ve ekip kaynaşamadığı sürece yine istenen sonuca ulaşmanız mümkün olmayacaktır. Ekibin üyeleri bireysel olarak ne kadar iyi olurlarsa olsunlar, birlikte çalışamadıkları zaman başarılı olmak hayal olacaktır.  Peki nasıl birlikte çalışma ortamı yaratılabilir

Birlikte çalışabilmenin anahtarı güvendir. Güven arttıkça işbirliği artacaktır. İşbirliğinin artması demek verimliliğin artması, ekibin etkinliğinin ve hızının artması ve de işin kalitesinin yükselmesi demektir. Peki güven nasıl sağlanır?

Güven için ilk adım empatiden geçiyor. Türkçe’ye duygudaşlık olarak çevriliyor. Benim anladığım
anlamı ise kendinizi başka birisinin yerine koyabilme ve onun gözünden anlama ve hissedebilme. Özellikle projelerde farklı rollerde çalışan insanlar birbirlerinin durumunu anlamakta zorluk çekebiliyor. Eğer herhangi bir yapıcı adım da atılmazsa “biz-siz” veya “biz-diğerleri” sınıflamaları ortaya çıkıyor. Bunun sonucunda da şöyle şikayetler artıyor:

• “Biz çok çalıştık, diğerleri çalışmadı.”
• “Biz haksızlığa uğradık.”
• “Bizim dediğimiz olmalı! Yoksa kendiniz yaparsınız.”
•  “Diğerleri işini iyi yapmadığı için kalitesiz oldu.”
•  “Diğerleri hata yaptılar ondan gecikti.”
•  “Biz olmadan bu iş olmazdı.”

Biz-siz algısının en keskin olduğu noktalarda empati kurulabilmesi en çok faydayı sağlayacaktır. Peki nerelerde empati gereklidir?

İlki müşteri-programcı arasında. Müşterinin gözünde genelde  programcılar, bahaneler üreten, disiplinli çalışmayan, denileni yapmayan, çoğu zaman iyi dinlemeyen, tembel ve zaman zaman da şımarık kişiler olarak canlanıyor.  Programcılar gözünde ise genelde müşteriler, ne istediğini tam bilmeyen, devamlı fikrini değiştiren, öngörüsü yeterli olmayan, teknolojiden bihaber, şikayet etmekten memnuniyet duyan ve zaman zaman da patronluk taslayan kişiler olarak canlanıyor.

İkincisi programcı-testçi arasında. Programcı gözünde genelde testçiler, bir türlü isteneni yapamayan, en ufak zorlukta bayrak kaldıran, denileni anlamayan, katı, tembel ve genelde programcı olmayı başaramamış kişiler olarak canlanıyor. Testçiler gözünde programcılar, işi bitirmeden teste sunan, aceleci, dikkatsiz, test ekibinin zamanından kullanan ve genelde burnu havada kişiler olarak canlanıyor.

Bu ön yargıları aşıp empati oluşturabilmenin bir kaç aşaması bulunuyor:

·       İlk adım elbette bir arada çalışmaktan geçiyor. Bir arada çalışma ister istemez iletişimi artıracak ve birbirini daha iyi anlama şansı verecektir.

·       İkinci önemli adım retrospektiflerin birlikte yapılabilmesi, bu konuda daha önce bir yazım bulunuyor (İlgili Makale: Çevik Yöntemlerde Retrospektif).

·       Üçüncü önemli adım ise iki tarafın birbirine talepleri dışında projeye ilişkin yaşadıkları zorlukları ve yönetmeye çalıştıkları durumları da açık yüreklilikle anlatabilmesi. Örneğin müşterinin yeni bir talebi ortaya çıktığında bunun neden ortaya çıktığı, bunu programcının önüne getirmeden önce neler yapıldığı, nasıl basitleştirilmeye çalışıldığı da anlatılırsa programcı da durumu ve müşteriyi daha iyi anlayacağı için daha farklı yaklaşabilecektir.

·       Dördüncü adım, herkesin kendi rolüne göre hedefler konulması yerine herkesi kapsayacak proje hedefinin ön plana çıkarılması, bireysel hedeflere ulaşmanın ödüllendirmede geri plana alınmasıdır. Örneğin programcı işini iyi yapsa bile ortaya çıkan ürün başarılı olamamışsa, kendisinin de başarılı sayılamayacağının hissettirilmesi.

·       Beşinci adım, birlikte yemek. Yemeği ekibin birlikte yemesi, ekip içi iletişimde arkadaşlık imkanlarını da artıracak, birbirini anlamaya katkı yapacaktır. Ne sıklıkla olacağına ekiple karar vermek en sağlıklısı olacaktır.

·       Altıncı adım, ekip devamlılığı. Eskiden İnsan Kaynakları politikaları personel devamlılığını sağlamak üzere optimize edilirdi. Artık bu yeterli değil, ekiplerin de devamlılığının sağlanabilmesi gerekiyor. Aynı ekibin sıradaki projelerde de birlikte çalışması hem çalışılan konudaki tecrübenin artmasına hem de ekipiçi güven ve işbirliğinin güçlenmesine fayda sağlayacaktır. Önümüzdeki yıllarda bu konunun daha çok önem kazanacağını düşünüyorum.

Sonuç olarak çevik yöntemlerin meyvelerini alabilmek için birlikte çalışmayı başarabilmek, takıma dönüşmek ve takımlara özgü güven ve işbirliğini tesis etmek gerekiyor. 

Çevik Yöntemlerde Retrospektif

Retrospektif (kimi yerlerde “geçmişe bakış” olarak geçiyor, TDK sitesinde tanımlı olduğu için bu haliyle kullanıyorum), çevik yöntemlerde daha önce yapılanların değerlendirildiği bir aşama olarak karşımıza çıkıyor. Özellikle iterasyon retrospektifi sık duyulan ancak içeriği hakkında fazla bilgi bulunmayan bir kavram. Bugün bu konuyu ele alıp “neden yapıyoruz”, “nasıl yapıyoruz”, “nelere dikkat etmeliyiz” sorularını yanıtlamaya çalışacağız.

Çevik yöntemlerde retrospektifin çıkış noktası hiçbir sürecin mükemmel olmadığı, iyileştirilebilecek yönleri olduğu gerçeğidir. İyinin daha iyisi hep vardır. Ayrıca değişime ayak uydurabilmek için her zaman geçmişte yapılanları inceleyip ders çıkarmak gerekir. Esasında sadece çevik yöntemlerle sınırlı değildir bu yaklaşım, tüm projelerinizde ve proje dışı işlerinizde geçmişe bakıp değerlendirme yaparak dersler çıkarmak ve iyileştirme yapmak mümkündür.

İterasyon retrospektifi en bilinen türüdür, iterasyon sonunda yapılır ve tüm ekibin katılımı istenir. Bunun dışında sürüm (release, çevik yöntemlerdeki anlamı tam da sürüm değil aslında, buna uygun başka Türkçe kelime önerisi varsa ve iletebilirse çok memnun olurum ) retrospektifi, proje retrospektifi de yapılır. Zamanı önceden planlanmamış sürpriz retrospektifler yapmak da mümkündür. Retrospektif yaparken izlenebilecek adımları altta iletiyorum, bunlar zorunlu olmamakla birlikte faydayı artırdığı tecrübe edilmiştir:

• Temel Talimat: Retrospektifler kişileri eleştirmek veya başarısızlıkları ortaya dökmek için yapılmaz. Bilakis herkesin tüm gayreti ile çalıştığı varsayımı üzerine hangi iyileri daha iyi yapabileceğimize dönük yapılır. Bunun altını net bir şekilde çizecek ve ekibi motive edecek bir “cümle” temel talimat olur. Herkesin bu talimatta mutabık kalması gerekir. Retrospektifin bu temel talimata göre yönetilmesi gerekir. Örneğin “Amacımız bağcı dövmek değil, üzüm yemek, daha iyi üzümleri yiyebilmek için buradayız. Lütfen kimseyi eleştirmeden sadece nasıl daha iyi üzüm yiyebileceğimiz üzerine düşünüp görüşlerinizi aktarın.”
• Beyin Fırtınası: Herkesin temel talimatta mutabık kalmasının ardından  bu aşamaya geçilir. Bu bölüm açık uçlu sorularla başlatılabilir. Sorulara gelen yanıtlarla kendiliğinden derinleşecektir.  Önemli tespitlerin herkesin görebileceği bir yere örneğin yazı tahtasına yazılması sonraki aşamalar için faydayı sağlayacaktır. Alternatif olarak bu bölüme başlarken yazı tahtasına sırasıyla şunlar ve istenirse ilave başlıklar yazılır: Eğlenceli/ Sıkıcı, Kolay/ Karmaşık, Benzer/ Farklı. Sonrasında bütün ekip üyelerinden bu başlıklara girebilecek konularla ilgili bu iterasyona ait deneyimleri istenir. Tüm ekip, öncelikle kendi önündeki kağıtlara yazar. Hangi deneyimleri artırıp neleri azaltmak istedikleri sorulur, bunlar da yazılır. Sonrasında sırasıyla herkesin görüşlerini açıklaması istenir. Aynı fikirde olunan konulara + eklenir.  Artırılması istenenlerin nasıl yapılabileceği sorularak konular tartışmaya açılır. Böylelikle iyilerin neler olduğu ve nasıl daha iyi olabilecekleri ekip tarafından ortaya konur.
• Sessizlik: Bu aşamada herkes susarak yazılanlarla ilgili ve bir sonraki iterasyonda nelerin iyileştirilebileceği ile ilgili düşünür. Fikirlerin tüm ekip tarafından anlaşılması ve hazmedilmesi için bu aşama çok önemlidir. Bu yapılmazsa toplantıda çok konuşan kişilerin sürüklediği dengesiz ve ekibin tamamını içine alamayan bir sonuç ortaya çıkar. Söz gümüşse sükut altındır sözü bu aşamayı çok güzel tarif eder.
• Oylama: Bu aşamada herkes tahtada yazılmış konulardan bir tanesini seçerek bir sonraki iterasyonda iyileştirilmek üzere işaretler. Çoğunluğun seçtiği konu tüm ekibin bir sonraki iterasyonda odağı olur.
• Odaklanma: Seçilen konuya tüm ekip odaklanarak nasıl iyileştirilebileceğine dair yeni görüşlerini belirtir.  Bir sonraki iterasyonda bu konudaki iyileştirme ekibin tamamı tarafında anlaşılıp kabul edilebilecek bir hedef cümlesine dönüştürülür.

Retrospektiflerde dikkat edilecek konulardan ilki tüm ekibin katılımdır. Tüm ekip üyelerinin konuşup görüş vermesi ve aktif katılımı, yapılan değerlendirmeyi daha da değerli kılacaktır.  Orada olmayan ekip üyeleri haliyle sonraki iterasyonun amacını kaçırması olasıdır.

Diğer dikkat edilmesi gereken konu retrospektif esnasında kişisel suçlama veya eleştirilere fırsat verilmemesidir. Eğer buna fırsat verilirse konu kolaylıkla çığırından çıkıp karşılıklı eleştiri boyutuna taşınabilir.

Son konu da retrospektifin süresinin sabit tutulmasıdır (time-boxing) ki bu da sürecin uzayıp konunun dağılmasını önleyecektir.

Başarılı retrospektifler çevik yöntemlerde (ilgili makaleler: Çevik Yöntemleri Uygulayabilmek, Çevik Yöntemlerde İş Analizi, Çevik Yöntemlerde Ekip Liderliği, Çevik Yöntemlerde Test Yönetimi ) ilerlemenin anahtarıdır. Retrospektiflerin iyileşmeye katkı yaptığı ekip tarafından görüldükçe, retrospektiflere olan motivasyon da artacaktır.  

Çevik Yöntemlerde Test Yönetimi

Test kavramı, yetenekleri, bilgi, beceri ve kabiliyetleri ölçme veya sınama olarak tanımlanıyor ve hepimizin aşina olduğu bir konu. Hem günlük hayatımızda hem de profesyonel iş hayatımızda çeşitli sebeplerle kendimiz veya ürettiklerimiz teste tabi tutuluyor. Matematik testi, zeka testi, kişilik testi, dayanaklılık testi, zemin testi, kandaki şeker testi, bakteri üreme testi, araç çarpışma testi, birim test, sistem testi, stres testi, regresyon (türkçesi bağlanım olarak geçiyor, kullanımı yaygın değil) testi, kullanıcı kabul testi vb. Hepsinde bir ölçme veya sınama söz konusu.

Test yapmazsak ne olur? Fatura öderiz. En temel örnek otomobil üreticilerinin bir hata tespit edip bazen yüzbinlerce aracını geri çağırmaları ve hem prestij hem de para kaybetmeleri. Bunu genişletmek mümkün: yıkılan yapılar, çalışmayan makineler, hatalı çalışan kodlar, sağlık sorunları, zararlı yiyecek/içecekler vb.

Testin esas amacı durumu anlama veya önlem alma veya düzeltme/iyileştirme olabiliyor. Tüm yazılım projelerinde olduğu gibi çevik yöntemlerde (ilgili makaleler: Çevik Yöntemlerde Ekip Liderliği, Çevik Yöntemlerde İş Analizi, Çevik Yöntemleri Uygulayabilmek) de testin önemi büyük. Bu önem de hatadan mümkün olduğunca arındırılmış kod üretebilmek ve bu sayede kullanım esnasında sorunsuz çalışmasını sağlayabilmekten ileri geliyor.

İster yazılım olsun ister başka bir endüstri test yönetiminde iki prensip çok işe yarıyor:

• İlki testi mümkün olduğu kadar erken aşamada yapmak veya başlatmak. Çünkü hata ne kadar erken fark edilirse düzeltme maliyeti o kadar düşük olacaktır. 
• İkincisi testi mümkün olan en geniş kapsam sağlayacak şekilde planlamak. Çünkü atlanan bir bölümde ortaya çıkacak bir hata, o kısmın test edilmesine ayrılacak maliyetten kat be kat yüksek olacaktır.

Yazılım projelerinde bu prensiplerden yola çıkılarak kod geliştirirken birim test; bileşenleri birleştirirken entegrasyon testi; birleştirilmiş ürünün çalışmasını görmek için sistem testi; son kullanıcıya göstermek için kabul testi; hataların düzeltilmesi esnasında farklı yerlerin etkilenip etkilenmediğini görmek için regresyon testi; performans beklentisinin karşılanıp karşılanmadığını görmek için performans testi planlanır. Bunların bazıları projeye ve ihtiyaca göre yapılmayabilir.

En kıymetli ve en az maliyetli test adımı olan birim testler maalesef genelde çok hafif geçilir veya atlanır. Çevik yöntemlerde tam da bu soruna bir çözüm öneriliyor Test Güdümlü Geliştirme (ingilizcesi Test Driven Development, Test Kontrollü Geliştirme de kullanılıyor). Burada amaç test durumlarına göre geliştirmeyi yapmak ve kodun testi geçecek kadar geliştirilmesini zorunlu kılmak. Temel adımları:

• Düşün (Think): Kodun ne yapması gerektiğini düşünüp bunları listeleyin.
• Kırmızı Çizgi (Red Bar): Testi listedeki fonksiyonlardan bir veya birkaçı için yazın. Mümkünse 5 satır veya daha az olsun.  
• Yeşil Çizgi (Green Bar): Testi geçecek kadar kod yazın ve testi geçin. 
• Kod Düzenleme (Refactor): Testi geçen kodu fonksiyonalitesini bozmadan iyileştirin. Fonksiyonun bozulup bozulmadığını gerekli yerlerde bir önceki adıma dönüp testi tekrarlayarak kontrol edin.
• Tekrar (Repeat): İyileştirilmiş koda ulaşınca, yeni bir fonksiyonalite için başa dönüp döngüye devam edin. Döngüden çıkış koşulu, listelenen fonksiyonalitelerin bitmesi.

Yukarıdaki yaklaşım ile önce testi sonra bu testi geçecek kodu yazarak önemli bir sıra değişikliği yapılıyor. Bu sayede henüz kodlama aşamasında bir çok hata tespit edilerek ortadan kaldırılıyor. İlk başlarda kodlama hızını düşürdüğü düşünülse de toplamda projeye hız katacaktır. Ayrıca buna alışan yazılımcıların hızlarının arttığı gözlenmektedir.

Test Güdümlü Geliştirme yanında kullanıcı hikayesi (ilgili makale: Çevik Yöntemlerde İş Analizi) yazılırken bunların arkasına testinin nasıl yapılacağının da yazılması gereklidir. Bu sayede geliştirilirken hangi durumlarda kullanılacağı ve nasıl test edileceği de biliniyor olacaktır. Hatta geliştirme aşamasında bunlar yukarıdaki döngüde Kırmızı Çizgi aşamasına da dahil edilebilecektir.

Bu kadar teste gerek var mı derseniz, yanıtım kesinlikle evet olacaktır. İyi test edilmemiş her iş faturasını er geç ödetir. Son söz olarak teste ayrılan zaman asla boşa gitmez, mutlaka bir faydası olacaktır, ya prestij ya para ya da emek kaybını önleyecektir.

Çevik Yöntemlerde Ekip Liderliği

Çevik yöntemlerle (ilgili makaleler: Çevik Yöntemleri Uygulayabilmek, Çevik Yöntemlerde İş Analizi ) ilgili önemli başlıklardan birisi ekip yönetimidir. Kimi zaman çevik yöntemlerde ekibin kendi başına tüm işi yaptığı, kararlarını kendi içinde aldığı, lidere de ihtiyaç duymadığı düşünülse de çevik yöntemlerde liderlik bir ihtiyaçtır. Klasik yönetim tarzlarının başarılı olamadığı, ekibe direktif verici yaklaşımların uygulanamadığı, ekibin kendi içinde karar alabildiği çevik yaklaşımlarda ekip yönetimi da haliyle farklı olacaktır. Peki çevik ekiplerle çalışırken nasıl davranacağız, nasıl liderlik yapacağız? Bu sorunun yanıtı arayacağız.

Eğer proje yönetiminden geliyorsak ve çevik bir ekibe liderlik yapmamız bekleniyorsa işi planlayıp plana göre takip etme alışkanlığından vazgeçmemiz gerekiyor. Çevik yöntemlerin dinamik planlama yapısı içinde ekibin planlamaya aktif katılmasına müsaade etmemiz ve proje boyunca planı revize etmemiz gerekiyor. Hatta en hassas olduğumuz kapsam yönetimi ve değişiklik yönetimi konularında bildiklerimizi bir kenara bırakmamız ve kapsamın projenin sonuna kadar değişmesine izin vermemiz gerekiyor. Başarı ölçümüzü müşteriye katma değer sunan ve çalışan uygulamalar olarak değiştirmemiz gerekiyor.

Eğer teknik yöneticilikten geliyorsak, direktif verici ve sıkı kontrole dayanan yönetim tarzını bir kenara bırakmamız gerekiyor. Ekibe yöneticilik yapmaktan vazgeçmemiz, liderlik özelliklerimizi ön plana çıkarmamız gerekiyor.

Çevik yöntemlerde başarılı liderlerin diğer liderlerle birçok ortak noktası var (ilgili makaleler: Liderlikte Enerji, Takım Formasyonu ve Liderlik, Mükemmeliyetçilik ve Liderlik, İnsan Nasıl Yönetilir?) bu yazıda onlara değinmeyeceğiz. Çevik yöntemlere özel ve önemli beceriler neler diye baktığımızda, alttaki başlıkların öne çıktığını görüyoruz:

• Ekibe koçluk yapma: Ekip üyelerinin kendilerini ve değerlerini tanıyarak potansiyellerini ortaya çıkarmalarına yardımcı olmak. 
• Ekip içi işbirliğini teşvik etme: Çevik yöntemlerde ekibin bir arada olması, birlikte çalışması ve işin sorumluluğunu hep birlikte üstlenmeleri sebebiyle iş birliğini ve yardımlaşmayı öne çıkarmak ve de teşvik etmek.
• Problemleri ekiple birlikte çözme: Problemleri çözümleriyle beraber sunmak veya kendi başına çözmek yerine ekiple birlikte çözülmesi için ortak aklı harekete geçirmek.
• Yaptıkları ve davranışlarıyla örnek olma: Liderliğin olmazsa olmazı olan hem kişiliği hem de yaptıkları ile ekibe ilham vermek.
• Yapılan çalışmanın müşteriye katacağı değeri ön plana çıkarma: Esas üretimin çalışan yazılım ve bunun müşteriye katacağı değer olduğunun altını gerekli noktalarda çizmek.
• Bürokrasi ve engelleri kaldırma: Ekibin dış etkenlere en az maruz kalması ve işlere odaklanabilmeleri için kurum içi bürokrasi ve engelleri temizlemek ve ekibin önünü açmak.
• Her detaya karışmama: Ekibin ne yapılması gerektiğini bilen, iyi niyetli ve çalışkan bireylerden oluştuğunu kabul etmek. Ekibe hareket alanı bırakmak. Yapılan işlerin tüm detaylarına hakim olmaya çalışmamak.

Her alanda olduğu gibi çevik yöntemlerde de iyi liderlik için eğitim ve tecrübe gerekir. Eğitim, zaten konuyu öğrenmek için gerekli, bunu tartışmaya gerek yok. Tecrübe ile kastedilen işi yıllarca aynı şekilde yapma değil, değişikliklere, farklı ekiplere, farklı tekniklere duyarsız kalmadan değişerek gelişmedir. Çevik yöntemler doğası gereği dinamik bir ortam sunuyor, müşteriden gelen değişikliklere yeşil ışık yakılıyor. Haliyle ekip liderinin de değişime ve gelişime açık olmasını beklemek gerekiyor.

Çevik Yöntemlerde İş Analizi

Çevik (agile) yöntemleri çoğumuz duymuşuzdur.  BT'de yaygın olan çevik yöntemler (ilgili makale: Çevik Yöntemleri Uygulayabilmek) ile ilgili hemen aklımıza hızlı şekilde kodlama gelir. Hep yazılım tarafındaki katkısı ve hızı düşünülür. Aslında çevik yöntemlere bu hızı kazandıran özelliklerden birisi hiç şüphesiz çevik iş analizidir. Peki çevik yöntemler içinde iş analizi nasıl yapılır? Bu sorunun yanıtını arayacağız.

Çevik manifestoda karmaşık dokümantasyon, uzun süreçler, müşteri ile sözleşme pazarlıkları ve katı planlar kabul görmüyor. Bunun yerine çalışan yazılım, etkileşim, müşteri ile işbirliği ve değişime ayak uydurabilme ön plana çıkarılıyor. Bunun karşılığını iş analizinde bulmak mümkün. Birçok dokümandan oluşan kimi zaman yüzlerce sayfayı bulan ve çoğu zaman da okunmayan dokümanlar yerine "Kullanıcı Hikayesi" (User Story) kavramı öne çıkıyor. Kullanıcı hikayesi ise müşteri veya kullanıcı için değerli olan özellik veya kabiliyet olarak özetlenebilir. Her bir özelliği/kabiliyeti ayrı ayrı olmak üzere kartlara yazarak bunların hem planlamada, hem detayları hatırlamada hem de test aşamasında kullanılması sağlanır.


Örnekler:

• Kullanıcı şifre ve kullanıcı adı ile sisteme giriş yapar.
• Kullanıcı x ekranından y verisini girer.
• Kullanıcı z verisini bilgisayarına kaydeder.
• ...

Teknik gereksinimler, altyapı ihtiyaçları gibi müşteriye anlamlı olmayan konular kullanıcı hikayelerinde yer almaz. "Uygulama Java'da yazılır." veya "Spring çatısı kullanılır" gibi bilgiler müşteri için anlamlı değildir.

Bir diğer konu da çok genel ve yüzeysel kullanıcı hikayelerinin yanıltıcı olabileceğidir, örneğin "Kullanıcı sisteme girip işlem yapabilir" gibi. Burada kullanıcının ne tür işlemler yapacağı, neleri yapamayacağı gibi konular havada kalmaktadır. Müşteri için anlamlı olan tüm kabiliyetlerin, teker teker yazılması en ideal yoldur. Yazılanların mümkün olduğu kadar atomik olması, planlamayı ve test işlerini kolaylaştıracaktır. Kullanıcı hikayesinin bağımsız, tahmin edilebilir ve test edilebilir olması da hem planlamayı hem de testi kolaylaştıracaktır. Eğer uygulamayı kullanacak birden fazla tipte kullanıcı varsa bu kullanıcılara göre tasniflenerek kullanıcı hikayesi yazılması en sağlıklısı olacaktır.

Kullanıcı hikayesini, müşteri veya müşteri adına ekipte yer alan iş analisti yazabilir. Yazılanların önceliklendirilmesi de yine müşteri veya onun temsilcisi tarafından yapılır. Her bir kullanıcı hikayesinin maliyeti (story points) işin büyüklüğü ve karmaşıklığı da dikkate alınarak yazılımcılar tarafından belirlenir. Sürüm ve iterasyon aşamalarında bu maliyetler, öncelikler ve yazılım hızı (iterasyon başına düşen ortalama story points) dikkate alınarak planlama yapılır. İterasyona giren kullanıcı hikayelerine dokunulmaz, dışında kalanlarla ilgili müşteri öncelik değiştirebilir veya yenilerini ekleyebilir.

İterasyon boyunca çalışılan kullanıcı hikayeleri için kabul testleri (acceptance testing) senaryoları kartların arkalarına yazılabilir. Bu şekilde istenen neydi, nasıl test edilecek bilgileri tek yerde toplanır. Tabi test için çeşitli araçlar kullanılan kurumlarda araca da girişi yapılabilir.

İterasyonla testi tamamlanıp kullanıma sunulan maddeler iş listesinden (çevik yöntemlerde ingilizcesi burndown chart, türkçe bilişim sözlüklerinde tam karşılığı bulunmuyor) düşülür. Proje boyunda yeni talepler de gelebileceği düşünüldüğünde genel trendi azalan ancak zaman zaman da yeni taleplerle artan bir grafik ortaya çıkar.

Sonuç olarak çevik yöntemlerde iş analizi önemini korur. Buradaki amaç uzun dokümanlar yerine ihtiyaçları basit, anlaşılır, kodlanabilir ve test edilebilir kullanıcı hikayelerine dönüştürmek ve bunları etkin şekilde kullanabilmektir.

Çevik Yöntemleri Uygulayabilmek

Son yıllarda özellikle BT sektöründe çokça duyulan ve popüler olan terimlerden biri de çevik (agile) yöntemler. Çıkışı 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 uygulanıyor.  1980'lerde Scrum ortaya çıkıyor. Burada da rugby oyunundaki toplu hücum toplu savunmadan esinlenilerek toplucu tüm işin yapılması temel felsefeyi oluşturuyor. 1990'lara gelindiğinde XP (extreme programming, ilgili makale: XP Nedir?), DSDM (Dynamic Systems Development Method) ortaya çıkarak çeşitli yerlerde kullanılmaya başlıyor. 2001'e gelindiğinde ünlü Çevik Manifesto yayınlanıyor, ö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

önem verilmesi olarak belirtiliyor. Scrum, XP, DSDM, FDD (Feature Driven Development), Crystal, LSD (Lean Software Development) ve diğer çevik yöntemler detayda bazı farklılıklar gösterseler de genel olarak yukarıdaki manifestoya uygun yaklaşımlardır.  

Temel itibariyle tüm projelerde çevik yöntemler uygulanabilir. Yukarıdaki manifestoyu baz alarak yaklaştığınız sürece tüm projeleri çevik tipte ele alabilirsiniz. Projeleri birkaç haftalık iterasyonlar olarak küçük parçalara bölerek yönetirseniz ve iterasyon sürelerini sabit tutarsanız (time-boxing) çevik yaklaşımın temel prensiplerini kullanabilirsiniz. Peki nasıl uygulayabiliriz? Aklınıza gelen bazı temel engelleri ve bunlara çevik dünyanın verdiği yanıtları alttaki şekilde özetleyebiliriz:

Çevik yöntemlerde dokümantasyonu nasıl yaparım? İterasyonlar içinde teslimatlar arasında dokümanları da tanımlayabiliriz. Dokümantasyonda aşırıya kaçmamak asgari yeter seviyede (barely sufficient) yapmak çevik yöntemlerin tercihidir. İstenirse dokümantasyon için ayrıca bir iterasyon (hand-off) ayrılabilir.

Kalite süreçlerini nasıl işletirim? Kalite süreçlerinde istenenleri, iterasyonlar içinde iş maddesi veya iterasyon sonunda kabul kriteri olarak planladığımızda kalite ekibiniz de memnun olacaktır.

Şirketimiz çağlayan modeli ile çalışılmasını tercih ediyor, ne yapabilirim? Çağlayan modelinde istenen çıktıları verdiğimiz sürece ekip içinde çevik yöntemlerle ilerlememize engel bir durum yoktur. Mümkün olduğu kadar müşterimizi işin içine katarak işbirliğini artırdığımızda çevik yaklaşımın meyvelerini yiyebiliriz.

Çevik yöntemlerde direkt kodlama yapabilir miyim? Çevik yöntemler kovboy kodlaması (cowboy coding) değildir. İşleri esnek bir plan dahilinde önceliklendirerek  yürütmemiz beklenmektedir. 

Çevik yöntemde kapsam, bütçe, zaman nasıl dengelenir? Sabit bütçe ve zaman olduğu varsayılarak kapsam serbest bırakılır. Müşterinin kapsamı yönetmesine izin verilir. Müşteri de kapsamı değiştirebildiği için mutlu olur. Çağlayan modelinde proje esnasında gelen değişiklik isteklerinin (change request) yerini ürün iş listesi (product back-log) alır.

Çevik yaklaşımda kapsam kontrolü nasıl yapılır? Ürün iş listesi ve bunun önceliklendirilmesi ile kapsam yönetilir. Burada kritik konu müşterinin fikrinin değiştirip iş listesinde henüz iterasyonu ve yazılım süreci başlamamış maddelerin önceliğini ve içeriği değiştirebilmesidir.  Eğer yeni madde ilave edilecekse karşılığında bir maddeyi çıkarmasını isteriz. Müşteri de vazgeçebileceği bir şey bulup bizi bu yükten kurtarır.

Ürün nasıl son haline getirilir? Ürünü toparlamak ve gerekli yerlerini düzenlemek için özel bir iterasyon (hardening, refactoring) planlayabiliriz.

Çevik yöntemlerde proje yöneticisi var mıdır? Elbette vardır, yöntemlere bağlı olarak adı değişebilir, örneğin Scrum Master, XP Koçu gibi. Klasik proje yönetiminden en büyük farkı ekibin işini kolaylaştırmak amacıyla ekibin önündeki engelleri ve bürokrasiyi kaldırmaya çalışır, ekibe yöneticilik yerine liderlik yapar. Sorun veya risk olan noktalarda devreye girer. Seçilen çevik yöntemin doğru uygulanmasını sağlar.

Çevik yaklaşımlardan maksimum fayda elde edilebilmesi için kurum olarak bu yöntemlerin benimsenmesi, üst yönetimin bu yolda tam destek sunması oldukça önemlidir. Müşterinin çalışmalara aktif katılımı da sonucu etkileyecektir.

Tüm projeler gibi çevik yaklaşımla yönetilen projeler de başarılı olmayı hedeflerler. Çevik yöntemlerde başarılı olabilmek için bol uygulama ve tecrübe çok önemlidir. Uygulama sayısı arttıkça hız kazanılması, eksikliklerin giderilmesi mümkün olur. Başarıyı etkileyen konular genel olarak diğer projelerle benzerlik gösterir (ilgili makale:Proje Başarı Kriterleri ve Proje İhtiyaç Analizi). Çevik yaklaşımın kendine özgü başarı anahtarları da vardır (ilgili makale: Çevik Yazılım Projelerinde Başarının Anahtarları Nelerdir?). 

Liderlikte Enerji

Herkesin enerji hakkında az çok bilgisi vardır. Hatta aklımıza hemen elektrik, doğal gaz, benzin gibi kavramlar da gelir. "Temiz enerji" ve "doğa dostu enerji" ise son yıllarda çokça duyduğumuz kelimeler, bunları da rüzgar tribünleri, güneş panelleri ile özdeşleştirmiş durumdayız. Fizikteki enerji tanımı cismin/sistemin iş yapabilme yeteneği olarak verilir; vardan yok yoktan var edilemez, dönüşür; çeşitli şekillerde bulunabilir; kinetik enerji, potansiyel enerji ise temel formlarıdır. Fizikteki bu tanımları kullanarak insandaki enerjiyi inceleyeceğiz. Liderlik elbette çok boyutlu bir kavram (ilgili makaleler: Takım Formasyonu ve Liderlik, Mükemmeliyetçilik ve Liderlik, İnsan Nasıl Yönetilir?, Başarılı bir CEO olur muydunuz?), bu yazıda sadece enerji açısından ele alacağız.

İnsandaki enerjiyi anlamak için süper kahramanlardan başlamakta fayda görüyorum. Enerji deyince aklıma ilk gelen atom karınca, yardım için oradan oraya koşturur, yorulmak nedir bilmez. Superman bile atom karıncanın yanında tembel kalır. En azından Clark Kent olunca dinlenme imkanı bulur :) Süper kahramanların enerjilerini nereden bulduklarını ise net değildir. Peki biz sıradan insanlara ne enerji verir?

• Yiyecekler 
• Renkler
• Müzik
• Kelimeler
• Düşünce ve duygular

Yiyecekler fiziksel enerjimizi sağlarlar, hepimizin bildiği ATP molekülü de bu süreçte anahtardır. Renkler ise duyguları harekete geçirerek enerji verir veya alır. Dinlediğiniz müzik eğer hoşunuza giden bir ritm içeriyorsa enerjinizi artıracaktır, beğenmediğimiz bir parça ise enerjimizi düşürecektir. Okuduğunuz, duyduğunuz ve söylediğiniz tüm kelimeler enerji içerir. İnsanların birbirlerine enerji aktarmalarını sağlar. Düşünce ve duygular da insanın enerji seviyesini ve enerjinin pozitif mi negatif olduğuna katkı yapacaktır. Hatta enerjimizi başka insanlara bazen kelimelerle, bazen bakışlarımızla bazen de duruşumuzla istesek de istemesek de aktarırız.

Liderler de ekiplerine enerji aktarır. Ekibin enerjisi sonuca yansır. Bu da yapılan işi, projeyi, uğraşı mutlaka etkiler. Liderdeki negatif enerji ekibe misliyle yansır, hem işe hem de ekip içi ilişkilere olumsuz etkiler. İyi liderlerin ise pozitif enerji yaymaları gerektiği söylenir. Peki liderler ne zaman pozitif enerji verirler?

• Çalışandaki potansiyeli anlamaya zaman ayırdığında: Bunun için çok iyi bir dinleyici olup (ilgili makale: Konuşma, Dinleme ve Proje Yönetimi) çalışanın hayallerini ve hedeflerini anlamak ve de hangi yöne kabiliyetleri olduğunu gözlemlemek gereklidir. Her insanın bir kabiliyeti, diğer insanlardan daha iyi yapabildiği bir şey vardır. Kimi insan bunun farkındadır, kimisi de farkında değildir. Farkında olmayanların keşfedebilmesi için liderlerin gözlemleri yardımcı olacaktır. İnsana eleştirel gözle yaklaşma, bir kusur bulma en kolayıdır. Kusursuz insan var mıdır dünyada? Maharet potansiyel bulmak ve bunu ortaya çıkarmaktadır.  
• Potansiyel  enerjiyi kinetik enerjiye çevirmeye destek olduğunda: Potansiyeli anladıktan sonra istek uyandırıp işe, oluşa yönelmesine yardımcı olmak, harekete geçmesine fırsat vermek gereklidir.  
• Çalışanlara koçluk, mentörlük yaptığında: Doğru budur diyerek insanların kabul etmesini beklemek en kolayı ancak en etkisiz olanıdır.  Bunun yerine çalışanlara ne yapacakları söylemeyip doğruyu bulmaları için kılavuzluk etmek ve gerekli yerlerde iyi sorular sorarak çalışanın kendiliğinden doğruları yakalamasına yardımcı olmak gelişim için iyi bir yaklaşımdır. 
• Çalışanların başarı ve başarısızlıklarını aynı olgunlukla karşıladığında: Başarısızlıkların da eğer nedenleriyle incelenirse çok iyi birer öğretmen ve de başarıya giden yolda kilometre taşları olduğunun bilinciyle yaklaşmak çalışanlara cesaret verecektir. Esas tehlike başarısız olmak değil başarısızlık korkusuyla hiçbir deneme yapmamaktır. Şu anda kullandığımız hemen hemen bütün araç gereçler onlarca bazen yüzlerce başarısız deneme ve bunlardan öğrenilenler sonucunda ortaya çıkmıştır. Eğer başarısız olmaktan korksaydı tüm insanlar, hala taş devrinde yaşıyor olurduk.
• Çalışanların katkı sağlamasına fırsat yarattığında: Her şeyi kendi bilip yapmak yerine ekibin de bir şeyler katmasına fırsat vermek, onların da yapılan işi sahiplenmelerini sağlayacaktır. Çorbada tuzu bulunan çorbadan daha çok lezzet alacaktır.
• Çalışanlarla birlikte öğrenmeye ve uygulamaya başladığında: Ekiple bir şeyler öğrenip bunu da hep birlikte uygulamak ekip ruhunu kuvvetlendirecektir.
• İlham verme ile değer vermeyi birlikte yapabildiğinde: Birçok kaynakta, liderlikte öne çıkartılan kavram ilham vermek ve etkileyerek peşinden sürüklemektir. Esasen değer vermek de en az ilham vermek kadar önemlidir, hele bu ikisini birlikte yapabiliyorsa işte o zaman gerçek anlamda lider olunabilir. Unutmamak gerekir ki "değer verildiğini hisseden değer katmak için çalışır".

Hepimiz hayatımızın bir parçasında lideriz. İş ortamında kimimiz CEO, Müdür, Proje Yöneticisi, Ekip Yöneticisi. Liderlik sadece iş ortamıyla da sınırlı değil elbette kimimiz spor takımı kaptanı, kimimiz dernek başkanı, kimimiz aile reisi, kimimiz abi/abla, kimimiz anne/baba. Her ne konuda liderlik yaparsak yapalım bizimle birlikte olan insanları dinliyor, anlıyor ve de değer veriyorsak, bizimle birlikte olan insanların tüm gayretiyle yapılana dahil olma, saygı ve de sevgisini kazanma şansına sahip oluruz. Ekip olmak sadece akıl işi değil aynı zamanda gönül işidir. Kalıcı başarıların anahtarı da işte budur.