Agile ile nasıl tanıştım;blogspot yazım

2009 yılında bir emniyet kritik yazılım projesi kapsamında kurulan yazılım ekibinde göreve başladığım zamanlarda proje ve sistem mühendisliği seviyesinde waterfall bir yaklaşım uygulandığını, yazılım seviyesinde “proof of consept” prototiplerin demoları ile müşteriye projenin ilerleyişi ile ilgili olarak bilgi verildiğini gözlemlemekteydim. O zaman kullanılan süreç artırımsal yazılım yaşam döngüsüydü. Bu döngü belli konfigürasyon parçalarının belirli bir artırımda tamamlanması felsefesi üzerine kurgulanıyordu. Ve genellik savunma sanayii projelerinde artırımsal yöntem tercih edilmekteydi. (Aslında bu yöntemin de scrum, lean veya kanban gibi iteratif bir yazılım yaşam döngüsü olduğunu belirtmekte fayda bulunuyor.)

Waterfall vs İteratif(Spiral,Incremental, Scrum..) yazılım yaşam döngülerini tanımaya ve idrak etmeye başlamam bu yıllara tekabül etti. Bu dönemlerde; 2001 yılında Agile manifesto(15 kişi tarafından) yayınlamıştı. 2010 yılında Scrum Rehber dökümanı yayınlanmıştı. Bu tarihler arasında agile yaklaşımların tam olarak vücut bulmaya başladığını söylemenin yanlış olmayacağını değerlendiriyorum. Dünyada yazılım alanındaki bu gelişmeler içinde bulunduğum yazılım ekip tarafından da takip edilmekteydi ve bu süreçte agile pratiklerinden bazı unsurları aslında konuya tam hakim olmasakta uygulamaktaydık. Teknolojik gelişmelerde bu süreci takip etmekteydi ve kullanılan araçlar ile birlikte gelen bazı unsurlar geliştricileri bu agile pratiklerini kullanmaya yöneltmekte olduğunu belirtebilirim. Benim çevik yaklaşımda ile ilgili o zamanlardaki uygulamalarım;İş takibini JIRA ile yapmak ve dolaylı da olsa çeviklik pratiklerinin bazılarını(değişime karşılık vermek, müşteri işbirliği gibi) JIRA sayesinde daha kolay uygulamak olarak özetlenebilir.

2012 yılına geldiğimizde ise bir arge projesinin proje yöneticiliğini, teknik liderliğini ve geliştiriciliğini yapmak gibi bir durumu tercübe etme fırsatı yakaladım. Bu proje kapsamda bildiğimiz pratikleri uygulayıp çözüm üretmeye çalışmıştık. Bu pratikler artırımlar tanımlamak, bilindik proje yönetim yaklaşımları(planlar oluşturma ve bütçe takip etmek vb.) uygulamak aynı zamanda Jira üzerinde en azında o hafta yapacağımız görevleri oluşturma diyebiliriz. Belirli iterasyon ve sprint yaklaşımız tam belirgin değildi. Ama aylık olarak faaliyetleri kapatmaya çalıştığımızı söyleyebilirim.2014 yılında bu projeyi başarılı bir şekilde kapattıktan sonra başladığımız uydu yönetim yazılımları geliştirme projesinde agile pratiklerini tam olarak uygulamaya başladığımızı söyleyebilirim. Bu dönemde büyüyen ekibimize katılan geliştiricilerin bir kısmının en az bir projede scrum tecrübesi vardı ve ekipten özellikle scrum yaklaşımlarının uyguılanmasına yönelik talepler artmaya başlamıştı. Tabiki “fix price” savunma sanayi projelerinde kullanım alanı henüz çok bulmamış bu yaklaşımla ilgili pek çok konunun etkili şekilde nasıl uygulanacağı konusunda pek çok soru işareti bulunmaktaydı. Bir önceki projemizin en önemli kazanılmış derslerinde biri bir iş için tahmin edilen efordaki sapmaların sürekli değişkenlik göstermesiydi. Bu durum aslında yazılım geliştirmenin doğasında var olan bir durumunun dışa yansımasının sonucuydu. Proje kapsamında aylık iterasyonlar tanımlıyor ve 6 ayda bir entegrasyonu tamamlanmış release alıyorduk. Agile pratiklerini yoğun bir şekilde kullandığımızı düşünmeme rağmen agile prensiblerini proje boyunca ekip olarak içselleştirerek uyguladığımızdan emin değildim. Diğer soruları yanıtlarken bu zorluklar ve kısıtlara daha fazla odaklanmaya çalışacağım. Agile ile tanışmam özetle benim için bir süreç/serüven olduğunu( öğrenmenin de bir süreç olması gibi) ifade edebilirim.

Agile metotları kullanırken kişisel olarak en zorlandığınız ve en çok verim aldığınız başlıklar şu şekilde sıralayabilirim. Agile çalışmanın temel zorluklarından biri olan müşteri ihtiyaçlarının değişmesi konusu bizim için çok zorlayıcı olmadı. Bunun nedenin projenin kurgusundan dolayı olduğunu söylemem gerekiyor. Doğrudan bir müşteri olmadığı için miatlara uyum konusunda daha esnek davranabiliyorduk. Çünkü platform bağımsız olarak diyebileceğimiz bileşenleri geliştirmeye odaklanmıştık. Platform bağımlı kısımları pilot proje üzerinde geliştirmeyi planlandığımız için bu durum bizi fazla etkilemedi diyebiliriz.

Takımın yapabileceklerinin sadece takımın tarafından bilinmesi ve bunun zamanla değişmesi durumu ilk başlarda yönetmekte zorlandığımızı düşünüyorum. Yetkinlikleri ortaya çıkarmak ve belki bir miktar rollerin oturmasının sağlanması; yani ekibin ekip olmasının zaman aldığını değerlendiriyorum.

Dünyamızda inanılmaz hızlı değişiklikler oluyor, ekonomik yapılar olsun, teknolojik değişiklik uzun soluklu projelerde sizin için dezavantaj oluşturabiliyor. Belirli bir teknoloji seçimine bağlı olarak kaldığınız tasarım kararlarını projenin sonlarına değiştirmeniz gerekebiliyor. Teknoloji seçimini yaparken baştan geleceğin teknolojilerine, geniş topluluğu olan araçlara yapmakta fayda olabilir. Belirli dönemlerde bu seçimleri tekrar ele almak maliyet etkinliği artırabilir.

Agile pratiklerini uygularken zorlandığımız bir konuda tek bir iterasyonu oluşturan tüm süreçlerin o iterasyon tamamlanması ve tanımlanan görevlere ait işlerin uzaması ve tekrar planlanması zorluğu olarak nitelendirebilirim.Bu zorluk aynı zamanda kolaylık, bir konuda tamamlanmayan işlerin tekrar planlanması ve iş bitinceye kadar takip edilemesi gerekiyor J. Herkesin o iterasyon için neyi yapacağı belli olduğu için ekip yapacağı işe daha kolay odaklanabiliyor. Temel prensiplerden birini ”Focus” olabilmek.

Başkaları adına taahhütte bulunamayacağınız başka bir gerçek;Bir önceki konun devamı gibi, iç içe geçen zincirin halkaları, bir işin tamamlanması ile ilgili bir problemi işaret etmektedir. ”completion of done” pradigması gerçek bir agile zorluğu olarak karşınıza çıkabilir. Testlerden geçen işleri tamamlanmış kabul etmek bir çözüm gibi gözüksede, tam istenilemi sağlamadığı durumlar olabiliyor. Her sürece bağlı “check list”’lerin ve tamamlanma kriterinin, görevin içinde senaryolar ile tarif edilmesi yöntemi değerlendirilebilir.

Agile çalışma metotlarının ekibinizin iş yapış şekline olumlu ve olumsuz yönde etkileri olabiliyor.Bu aslında ne kadar ekip olduğunuzla ve personel devir oranına bağlı olduğu kanaatindeyim. Ekibe katılan ve ayrılan kişiler ekip üzerine ve kültürüne etki ediyor. Aslında her katılan kişi ile ekibin tekrar uzlaşma(konsensüs) oluşturması ve birlikte ekip kültürünün yeniden oluşturması işin doğasında yer alıyor. Ekibe yeni katılan kişilere uygulanan pratiklerin ve prensiplerin çokiyi açıklanmasını tavsiye ediyorum. İşi kendi aralarında kurdukları uzlaşıya dayalı prensipler ile yerine getirdiklerinden dolayı işi bitirmek ve eksikleri kapatmak için beraber hareket etmek zorunda olduklarının farkında olmaları gerekiyor

Agile çalışma metotları yaptığınız işin verimini artıracaktır. Ama bunu için ekibinizin problemleri çözebileceğine güvenmeniz gerekiyor. Güveniniz ile onları motive etmeyi başardığınızda ve aralarında gerekli uzlaşma tabanlı iş akışını oluşturduğunuzda yüksek verim gerçekleşecektir. Tabiiki tüm ekip üyelerinin verilen taahhütlerin ekibin başarısını etkilediğini, bireysel başarıların gerçek değere ulaştırmadığını iyice anlaması gerekmetkedir.

Şirket içinde bölüme bağlı olmak üzere birimlerin çok fazla müşterisi olabilmektedir. Verilen taahhütlerin ve uygulanan pratiklerin paydaşlara/müşteriye doğru ve açık bir şekilde anlatılması gerekmektedir. Oluşan anlaşmazlıklar konusunda kendinden farkındalığınızın yüksek olması gerekiyor. Hiyerarşik yapılanma içinde olduğumuz için bu anlaşmazlıkların doğru noktada çözülmesi gerekmektedir.Planlamanın ekip tarafından iyi anlaşılması ve uygulanması gerekir. Herkesin büyük resmi gördüğünden bir miktar emin olmak gerekiyor. Çevik olmanın en büyük unsurlarında biri kapsamdaki değişikliklere açık olma unsurunu zamanla insanlar unutabiliyor. Bir başka bir hususta bu yönlendirme altında ekipleri kendi kendilerine organize olup, patinaj yapılan yerlerde tekeri döndürebilmeleri olarak karşınıza çıkıyor. Ekibin içinde kişilerin çoğunluğunun taahhüt vermekte çekingen kalmalarına dikkat edilmelidir. Bu ekip içi güvenin oluşmamasından kaynaklanabilir.Bu durumla başa çıkmak için güvenilirliği herkesin tarafından önemsenmesinin sağlanması faydalı olabilir.

Agile yöntemleri yeni kullanacak bir yöneticinin çevik olmanın bir süreç olduğu,bu süreci yönetirken kendi farkındalıklarını artırması gerektiği bilinci ile hareket etmesini tavsiye ederim. Bir yöntemin uygulanmasını en iyi onu iyi bilen ve benimseyen kişilerin sağladığı kabul edilmelidir. Siz mükemmel bir yönetici olabilirsiniz ya da süreçlere çok iyi hâkim olabilirsiniz, ama kültürel değişim olmadan çevik bir başarı elde edilemeyeceğini kabul etmelisiniz.

Sizi izlemesini beklediğiniz diğerlerine bir model olabilmelisiniz. Çevikliği benimsemeli, söyledikleriniz ile ve yaptıklarınızla iyi bir çevik yaklaşımcının ne olduğunu/yaptığını diğerlerine göstermelidir. Yetkinliklerinizi/Yeteneklerinizin farkında olmalsınız ve özellikle gelişmeye açıkyönlerinizi tanımlanmalı ve onların üzerine gitme cesaretini gösterebilmelisiniz.Bir yeteneğinizi geliştirip diğerine geçebilmelisiniz. Aşırı kontrolcü olamktan kaçınmalısınız.Tecrübe ettiğim için söyleyebilirim ki,bu gerçekten çok zor olabilir. Kurum kültürü,toplumsal yapı gibi unsurlar bunu gerçekleştirmeyi oldukça zorlaştırıyor.

Yeni pratikler keşfemeye çalışmalı ve bu pratikleri günlük faaliyetlerinize yansıtmaya çalışmalısınız.Ayak üstü 15 dk geçmeyen toplantılar yapmak veya çatışma durumlarının çözümü üzerine uygulanabilecek yaklaşımlar geliştirmek örnek olabilir. Dinlemeyi ve konuşmayı ve ekiple birlikte olmayı öğrenmelisiniz.En iyisi doğru soruları (çok önemli,ne yapmaları gerektiğini söylemek çözüm olamyacaktır) doğru zamanda sormaya çalışmalı ve İnsanlara sunduğunuz aynı şefkat ve desteği kendinize de uzatmalısınız, kendinize de doğru soruları sorun,yani koçluk yapmalısınız.

Agile ile ilgili tecrübe ettiğim süreçlerin ve olayların bir kısmını, çok önemli olduğuna inandıklarımı ve hatırlayabildiklerimi aktarmaya çalıştım.