Agile Manifesto‘da şundan ziyade buna değer verelim, ‘şu’nların önemini biliyoruz, ‘bu’nlara daha çok değer veriyoruz derken çeviklik değerlerini tanımlamışlar. Basitçe ne demek istemişler bir bakalım:

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

Projelerimizde kullandığımız süreçlerin ve araçların önemi yadsınamaz. Ancak bu süreç ve araçları kullanan kişiler ve birbirleri ile etkileşimleri daha önemlidir. Problemleri araçlar değil insanlar çözer. O sebeple takım üyelerine odaklanmalıyız. Aynı şekilde takım üyelerinin süreçler ve araçlar ile etkileşimi de önemlidir. Ne kadar basit, uygulanabilir, dinamik ve sonuç odaklı süreçlerimiz ve araçlarımız mevcut ise hedefe ulaşmamız o kadar mümkün olacaktır.

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

‘Her projenin amacı müşterisine ya da kullanıcısına vaat ettiği ürünü zamanında, kaliteli ve başarılı olarak teslim etmektir. Teslim etme anına kadar gereksinim analizi, tasarım, ekran tasarımları, UML Diyagramları, proje yönetimi planı, kurulum planı gibi dokümanları tam ve eksiksiz olarak sorumluları tarafından oluşturmasıdır.’Yanlış bir önerme değil (gibi). Ancak bu durum bazen öyle bir hale gelebilir ki doküman üründen önemli hale gelebilir. Örneğin, İlerleme Raporu UML Diyagramından daha önemli midir? Ne yazık ki 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ı? Tabii ki hayır! Hem de kocamanından bir hayır! 

Sistemin Gereksinim Analizi bize istenen sistemin özelliklerinin ne olduğunu belirtir. Ancak tüm sistemin gereksinim analizini bir kerede ortaya koymaya çalışmak gerçekçi değil. Bunu gerçekleştirsek bile proje süresince çeşitli değişiklik istekleri ile karşılaşacağımız olasıdır. Agile Manifestonun bu maddesinde önerilen işimize yetecek kadar dokümanı ortaya çıkarmamızdır.

Ne kadar doküman yazmalıyız? Burada iki kriter var: yazılan her dokümanın ürüne bir 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ünü oluşturur gibi dokümantasyon da adımsal ya da arttırımlı olarak geliştirilebilir. Bu yarım bırakılmış dokümanlar manasına gelmez. O anda işimize yarayacak bilgileri içeren doküman içeriği vurgulanmaktadır.

3.       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 gelen resmi gayrı resmi tüm istekleri gerçekleştirin denmiyor. Tabii ki sözleşme yapacağız ki sınırlarımızı belirleyelim, değişiklik isteklerinin değerlendirmesini de yapacağız ki sistem hep beklendiği gibi çalışmasını engellemeyecek şekilde bu istekleri gerçekleştirelim ya da gerçekleştirmeyelim.

Müşterimizle kapsam savaşları yapmak yerine ürüne değer katacak değişiklik isteklerini yine müşterimizin geliştirme sürecine katılımını sağlayarak değişikliklere açık olmamız önerilmektedir bu maddede. Böylelikle ürünün ne olacağı konusunda ortak anlayışımız oluşacaktır.

Geliştirme süreci ilerledikçe hem geliştirme takımında hem de müşteri tarafında ürüne değer katacak, faydayı arttıracak işlevselliklere ve özelliklere sahip ürün ortaya çıkması kaçınılmaz olacaktır.  

Müşterimizle yapacağımız sözleşmeler daha esnek olacaktır. Agile çalışmalarda sabit fiyatlı sözleşme yapılamaz mı diye bir soru gelebilir aklınıza. Tabii ki yapılabilir. Çeviklik yaklaşımı bunu da destekler.

Bu maddeyle ayrıca değişiklik yönetimi sürecinin verimli ve etkili bir şekilde kurulduğunda sözleşme pazarlıkları kaliteli ürün sağlamanın önüne geçmemesi gerektiği önerilmektedir.

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

Başlangıçta yaptığımız planlara uyuyor muyuz? Her proje başında ayrıntılı bir şekilde Gantt Şeması yapıyoruz peki bu şemaya uymak (ya da uymaya çalışmak) kaliteli ürün üretmenin önüne geçiyor mu? Proje denetime gireceği zaman kaç gecenizi Gantt Şemasına uygun iş dağılımı yapmış mıyım diye kontrol ediyorsunuz?

Şu anda aklınızdan planlamanın gereksiz olduğu geçiyor şimdi değil mi? Peki Agile Manifestosu’nun bu maddesi bize planlama yapmamamızı mı öneriyor? Tabii ki hayır ‘Planning is still king!’

Çeviklik bize yeterince ve sürekli planlama yapmamızı hatta yaptığımız planlardan bir anda da vazgeçmeye hazır olmamızı öneriyor.

Son Söz

Ürün geliştirme deneysel bir süreçtir. Yolun başındayken bilmediğimiz pek çok konu bulunmaktadır. Çevik planlama yapmanın en güçlü yani bilmediğimiz konularda var olan engelleri ortadan kaldırmaya çalışmak yerine önce bildiklerimizden başlamamızı desteklemesidir.

İstesek de istemesek de planımız değişecek, önemli olan şey bu değişime ayak uydurmamız. Çeviklik yaklaşım bizim planlamaya daha doğrusu yeniden, tekrar tekrar planlama yapmaya daha çok önem vermemizi istiyor. 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. Bu da bizim hareket kabiliyetimizi arttıracaktır.