Agile Değerler

agile

“Bizler daha iyi yazılım geliştirme yollarını uygulayarak ve başkalarının da uygulamasına yardım ederek ortaya çıkartıyoruz.
Bu çalışmaların sonucunda:
Süreçler ve araçlardan ziyade bireyler ve etkileşimlere
Kapsamlı dökümantasyondan ziyade çalışan yazılıma
Sözleşme 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 vermeye kanaat getirdik.
Özetle, sol taraftaki maddelerin değerini kabul etmekle birlikte, sağ taraftaki maddeleri daha değerli bulmaktayız.”
(http://agilemanifesto.org/iso/tr/manifesto.html)

Çevik Manifesto Değerleri Bize Ne Anlatıyor?

Manifestoda şundan ziyade buna değer verelim, ‘şu’nların önemini biliyoruz ancak ‘bu’nlara daha çok değer veriyoruz demişler. Şimdi ‘Şu’ ve ‘Bu’ maddelerine tek tek bakalım:

Süreçler ve araçlardan ziyade bireyler ve etkileşimlere değer vermek

Yeni ürün, hizmet ya da sonuç geliştirmek için çalışmalarımızda kullandığımız süreçlerin ve araçların önemi yadsınamaz. Bununla birlikte süreç ve araçları kullanan kişiler ve birbirleriyle etkileşimleri sürecin ve aracın kendisinden daha önemlidir.

Problemleri araçlar değil insanlar çözer. O sebeple takıma, takım üyelerine, çıktıdan etkilenecek kişilere odaklanılması önemlidir. Ayrıca kişilerin süreçler ve araçlar ile nasıl bir etkileşim içinde oldukları da önemlidir.

Yani, ne kadar yalın, uygulanabilir, dinamik ve sonuç odaklı süreçlerimiz ve araçlarımız mevcut ise amaçlanan hedeflere ulaşmamız o kadar kolaylaşır ve mümkün olur.

Peki bu nasıl olur?

Yalınlık

Kişiler tarafından bilinen ve neden uygulandığı konusunda ortak anlayışın ve farkındalığın olduğu yöntemler, araçlar ve ilkelerin uygulandığı, değer akış analizinin açıkça ortaya konduğu verimliliği ve etkililiği kanıtlanmış akışı belirgin ve en yüksek seviyede değer yaratmak yalınlığın başta gelen unsurlarıdır.Doğru işi, doğru zamanda doğru kişinin yapması da yalınlığa etkisi vardır.

Dinamiklik

Aynı şirketin geliştirdiği her ürün aynı adımlar uygulanarak elde edilse de ürün geliştirmede takımı o ana özgü ya da kendine has sıkıntılar yaşayabilir. Müşteri, teknoloji ya da çevre gibi sebeplerden dolayı farklılaşmalar olabilir. Takım her an farklı bir durum ile karşılaşabilir. İstisnai durumlarda kendisini konumlandırabilen takım ve farklı yaklaşımlara açık bir süreç yönetimi ile dinamik olunmasını sağlar.

Sonuç Odaklılık

Kilit süreç ve araçların organizasyonda her kademe için birbirini destekleyecek biçimde belirlenmesi sonuç odaklılığı pekiştirir. Şirket stratejisi açısından müşteri memnuniyeti, yazılım geliştirme açısından kod gözden geçirme kilit süreçler olabilir ve her iki süreç de birbirini destekler. Daha az hatalı ürün daha çok müşteri memnuniyeti sağlama olasılığı yüksektir. Ürün sorunsuz ise müşteriniz bunu söylemeyebilir ama hatalı ise bunu kesinlikle duyarsınız.

Kapsamlı dökümantasyondan ziyade çalışan yazılıma değer vermek

Yeni ürün ya da hizmet geliştirme işi proje başlatılrak yapılmaktadır. Proje kavramı çoğu şirket için artık günlük bir konu. Bir projede onlarca hatta projesine göre bazen yüzlerce doküman üretilir.

Her projenin amacı müşterisine ya da kullanıcısına vaad ettiği ürünü zamanında, kaliteli ve başarılı olarak teslim etmektir. Teslim etme anına kadar ürünle ilgili olarak gereksinim analizi, tasarım, ekran tasarımları, UML Diyagramları gibi teknik dokümanların tam ve eksiksiz olarak oluşturulmasına önem verilir. Proje planı, risk planı, ilerleme raporu gibi yönetimsel dokümanlar da titizlikle hazırlanır.

Ancak bu durum bazen öyle bir hale gelebilir ki doküman yazılması üründen daha kıymetliymiş gibi olur.. ‘Proje İlerleme Raporu’ ‘Kullanıcı  Ara Yüzü’ tanımlamasından daha önemli hale gelebilir. GELMEMELİDİR.

Kesin Bilgi: Ne yazık ki -hala- tam ve eksiksiz dokümantasyon ile çalışan ürün arasında bir ilişki henüz dünyada ortaya konamamıştır.

Peki, doküman yazmayalım mı? Hazır bu değer de bize öyle söylerken es geçelim şu doküman işini. Tabii ki hayır! Hem de kocamanından bir hayır!

Bir örnekle açmak istiyoum:

Sistem Analizi dokümanı bize istenen sistemin özelliklerinin ne olduğunu belirtir. Ancak tüm sistemin analizini bir kerede ortaya koymaya uğraşmak her sistem için gerçekçi değildir. Bunu gerçekleştirsek bile proje süresince mutlaka çeşitli değişiklik istekleri ile karşılaşırız.  Bir anda BTK, BDDK ya da başka bir denetleyici kurumun regülasyonu değiştirmesi sistemimizde mutlaka gerçekleştirmemiz zorunlu olan yeni bir gereksinim ortaya çıkartabilir. Agile Manifestonun bu maddesinde önerilen işimize yetecek kadar, gideceğimiz yolu görecek kadar doküman oluşurmamızdır. – Tabii ki projesine, sistemin kritikliğine, müşterisine vb göre bu olmayabilir, işin başında bu yaklaşımın uygun olup olmadığı şirket tarafından mutlaka değerlendirilmelidir.

Bu durumda yeni bir soru karşımıza çıkmaktadır: Ne kadar doküman yazmalıyız?

Burada -bence- iki kriter var: yazılan her dokümanın ürüne yada sonuca faydası ve katkısı olmalıdır. Çevik yaklaşım o an için işimize yarayacak kadar dokümantasyon yazmamızı söylemektedir. Proje ürünü gibi dokümantasyon da adımsal ya da arttırımlı olarak geliştirilebilir. Bu yarım bırakılmış dokümanlar manasına gelmemektedir. O anda işimize yarayacak bilgileri içeren doküman içeriği vurgulanmaktadır.

Çevik yaklaşım ‘backlog’ yani liste oluşturulmasını öne çıkarır. Ürünün ya da sonucun gerçekleştirilmesine destek olacak kriterler eklenerek istenilen derecede ayrıtılandırılabilir bu listeler. Örneğin ‘İş Listesi’ni ele alalım – ‘Product Backlog’. her ne kadar Scrum Kılavuzu’nda Ürün iş Listesi olarak çevrilse de her alanda kullanılabilecek yalın bir kullanımı tercih ediyorum.

İş Listesi elde edilmek istenen ürün, hizmet ya da sonuçla ilgili olarak ilk etapta çok da detaylı olmayan, hangi özelliklere sahip olacağını, aşağı yukarı neye benzeyeceğini bize madde madde söyler. Çeşitli kriterlerle derinleştirilebilir.Her bir madde için zorluk, risk, belirsizlik, kullanım alanı gibi kriterlerle hedeflenen son ürünün özellikleri ortaya kademe kademe çıkartılır. Yani hedefe faydası ve katkısı olacak şeylere kafa yorulur.

Sözleşme pazarlıklarından ziyade müşteri ile iş birliğine değer vermek

Agile Manifeso’nun bu maddesinde ‘müşteriniz ile sözleşme yapmayın, müşterinizden size bir şekilde iletilen resmi ve gayrı resmi tüm istekleri yerine getirin’ DENMEMEKTEDİR.

Tabii ki müşterimizle sözleşme de yapacağız, değişiklik isteklerini de alacağız.

Bu maddede şairin vurguladığı şey müşterimizle kapsam savaşları yapmak yerine müşterimiz için değerli ürün  geliştirmeye odaklanalım. Bunu da müşterimizi geliştirme sürecine en yüksek seviyede katılımlarıyla ve değişikliğe açık olmakla gerçekleştirebiliriz.

Birlikte takım olarak çalışarak ürünle ilgili beklentilerin ne olduğu, ürünün hangi özelliklere sahip olacağı ve ürünün nasıl çalışacağı ve konusunda ortak anlayış oluşur. Geliştirme süreci ilerledikçe hem takımda hem de müşteri de katma değerli ürüne ve faydayı arttırmaya yönelim güçlenir ve gerçekleştirilir.

Aslında amaç değişiklik yönetimi ve/veya talep sürecinin verimli ve etkili kurulması aynı zamanda dinamik olacak şekilde konumlandırılmasıdır. Sözleşme pazarlıkları müşterimiz için değerli ürün , hizmet ya da sonuç elde etmenin önüne geçmesine izin verilmez.

Müşterimizle yapacağımız sözleşmeler her zaman yaptığımız sözleşmelerden farklı olarak daha esnek olacaktır. Amma burada çevik sözleşmeler konusuna girmek istemiyorum. Bu çetrefilli konuya başka bir yazıda geliriz.

Bir plana bağlı kalmaktan ziyade değişime karşılık vermeye değer vermek

Her şeye planlayarak başlarız. Peki, başta yaptığımız o planlara uyuyor muyuz? Ayrıntılı Gantt Şeması yapıyoruz örneğin. Bu şemaya uymak kaliteli ürün üretmenin önüne geçiyor mu yoksa bu şemayla ara ara oynayıp değiştiriyor muyuz? Projenin denetim tarihinden önce kaç gecenizi Gantt Şemasına uygun iş dağılımı yapıp yapmadığınızın kontrolü ile geçiyor?–sabunlama demedim bakın dikkatinizi çekerim.

Aklınızdan planlamanın gereksiz olduğu geçiyor şimdi değil mi? Hem Agile Manifestosu’nun bu değeri de bize sanki planlama yapma der gibi gibi. Öyle değil:

  • Her şey değişebilir, buna açık olmalısınız.
  • Ekip, vazgeçmeye ve yeniden başlamaya hazır olmalıdır.
  • Değişim kötü bir sonuç değildir, fırsatlar içerebilir.
  • Plana uyAmamak felaket değildir. Yeniden planlama yapmak iyidir.
  • Yeniden planlama yapmak planlarla oynamak değildir, değişim olduğunda bu değişimi gözeterek planı iyileştirmektir.

Çeviklik Değerleri İle İlgili Son Söz

Yeni bir ürün, hizmet ya da sonuç geliştirme deneysel bir süreçtir. Tüm iş bu sürecin doğrudan, aktif ve dinamik olarak yönetimidir. Kişiler ve aralarındaki etkileşim önemlidir, hatta en önemlisidir.

Yolun başında bilmediğimiz ve farkında olmadığımız pek çok konu vardır. Çeviklik yaklaşımının en güçlü yanı belirsizliğin olduğunu kabul etmesidir. Bu farkındalıkla işler yapılır.

İstesek de istemesek de planlarımız, işin kapsamı ya da başka bir şey değişecektir, önemli olan değişime ayak uydurmaktır. Yeniden ve tekrar tekrar plan yapabiliriz, sıkıntı yok. Planların gerçekleşmemesi bizim için felaket olmayacak, aksine neden planlanan gibi gitmediğini değerlendirip, yeniden planlama yapmamızı sağlayacak. Uyumsuzluk gibi görünen öğeler bize süreç iyileştirme fırsatı yaratacak, ürünün değerini arttırmaya yönelik gelişim sağlayacak.