Çevik Manifesto Ne İfade Ediyor?
Çevik Metotlar Hangi Projelerde Kullanılmalı? makalemde de ele aldığım, yazılım projelerinde ortaya çıkan farklı ihtiyaçlar doğrultusunda sektörün önde gelen entellektüelleri tarafından daha iyi yöntemlerle nasıl yazılım geliştiririz diye kafa yorulmuş ve farklı bir yaklaşım ortaya konmuştur.
Bu yaklaşımı 4 maddelik bir manifesto ile yayınlamışlardır. Manifestoya göre her bir maddenin soldaki ifadesine sağdaki ifadeye göre daha fazla öncelik verilmesi gerekmektedir. Bu sağdaki ifade önemsiz anlamına gelmemektedir ancak; önceliğimiz çevik yaklaşımda soldaki ifadeler olmalıdır. Aşağıda manifestonun orijinal ifadelerine dokunmamayı tercih ettim.
Individuals and interactions over processes and tools
Geleneksel proje yaklaşımında işin yapılışını ince detaylarla tarif etmeye çalışan süreçler ile bunları destekleyen araçların kullanıldığını görürüz. Çevik yaklaşıma göre aslolan bireyler ve aralarındaki etkileşimdir, çünkü işi yapanlar süreçler ve araçlar değil bireylerdir. Ne kadar yetenekli bireylerle çalışırsak, takım içerisindeki iletişim ne kadar iyi olursa başarma ihtimalimiz de o kadar yüksek olur. Cocomo tahminleme modeli de bu söylediğimi teyit eder niteliktedir. Bir projenin büyüklüğü hesaplanırken çalışanların yetkinliğinin etkisi süreçlerin olgunluğuna oranla çok daha yüksektir (1’e 10 gibi bir oran). Bu durum tabi ki süreçlerin tamamen önemsiz olduğunu göstermez, organizasyon tarafından bir çalışma çerçevesi belirlenmesi herkesin kendi kafasına göre iş yapmasının önüne geçecektir. Ancak bu çerçevenin çok katı olmaması, ekipler tarafından uyarlanabilir bir yapıda olması gerekmektedir. Farklı projelerin farklı ihtiyaçları olacaktır.
Working software over comprehensive documentation
Geleneksel yaklaşımda projenin erken fazından itibaren detaylı proje dokümanlarının (detaylı plan, gereksinim, tasarım dokümanları gibi) üretilmeye çalışıldığını görürüz. Yazılım projelerinin doğasından kaynaklanan belirsizlik, en başta detaylı planlama ve analiz gibi faaliyetlerin yapılmasını zorlaştırmaktadır. En başta bunları çok detaylandırmak, zaten değişmesi çok muhtemel konular için proje başlangıcında gereksiz efor harcamaya sebep olur. Çevik manifesto bunun yerine müşteri için en faydalı çıktı olan yazılım teslimatlarına daha çok öncelik verilmesini önerir. En başta detaylı plan yapmak yerine yazılımın bir sonraki sürümüne odaklanır, bu sürümün kapsamını ilk aşamada detaylandırırız. Bu şekilde erken fazda yazılım sürümlerini teslim ederek geri bildirimleri almayı amaçlarız. Peki tamamen yol kervanda düzülür mantığıyla mı hareket ediyoruz ? Tabi ki hayır, projenin erken fazında tüm kapsamı gösteren üst seviye bir yol haritası (high level roadmap) da tanımlanır. Bu yol haritasında üst seviye gereksinimler epiclerolarak tanımlanır ve kullanıcı hikayesi (user story) detayına girilmez. Ekiple birlikte projenin hangi döneminde ne teslim edilecek üst seviyede tespit edilir. Proje ilerledikçe iterasyonlar planlanırken kullanıcı hikayeleri de önceliklendirilip detaylandırılır. Bu yaklaşımda planlar proje ilerleyip detaylar ortaya çıktıkça değişime açıktır. İlerleyen zamanlarda çevik planlamayla ilgili paylaşımlar da yapmaya çalışacağım.
Customer collaboration over contract negotiation
Proje yapıyorsak elbette bir sözleşmesi ve müşteriye verdiğimiz bazı taahhütler olacaktır. Ancak orta ve büyük ölçekli yazılım projeleri gibi başlangıçta her detayın planlanmasının mümkün olmadığı projelerde, sözleşme kapsamını ince detaylarda tanımlamaya çalışmak ileri safhalarda değişime ihtiyaç duyulduğunda bize ayak bağı olacaktır. Proje sırasında müşteri ile daha yakın çalışarak ihtiyacın daha iyi anlaşılması ve gereksinimlerin detaylandırılması sağlanmalıdır. Bu nedenle hukuksal açıdan iki taraf için de bağlayıcılığı olan sözleşme üst seviye bir çerçeve çizmeli, çerçeve içindeki detaylar müşteri ile çalışılmak üzere ileriki safhalara bırakılmalıdır.
Peki sözleşmede ne kadar detaya girilmeli ? Bunun için sözleşme aşamasında müşteri ile birlikte yapılacak ihtiyaç analizi önemli. Sorunlar, darboğazlar, projeden beklentiler nedir ? Paydaşlarla birlikte bunun analizinin yapılması gerekli. Bunun sonucunda üst seviye bir bakış ile hangi ürünlere ihtiyaç var, bu ürünlerin modül kırınımları ne olacak ? Ürün-modül kırınımının belirlenmesiyle her bir modülden hangi ihtiyaçları karşılaması bekleniyor ? Bu çalışma sonucunda belirleyeceğimiz ihtiyaçlar bizim teknik istek setimizi oluşturacaktır. Teknik istekler yazılım gereksinimi seviyesinde olmayacak, proje başladıktan sonra detaylı analiz aşamasında müşteri ile gerçekleştirilecek çalışmalarla yazılım gereksinimleri ortaya çıkacaktır.
Responding to change over following a plan
Plansız proje elbette olmaz. Ancak değişimin kaçınılmaz olduğu yazılım projelerinde başlangıçta çok detaylı bir plan yapıp bunu uygulamak pek mümkün değildir. Yukarıda da ifade ettiğim gibi bazı detaylar ilerleyen safhalarda netleşecektir. Örneğin orta ölçekli, 2 yıl süreli bir projede her ay sonunda yapılacak teslimatın kapsamını projenin en başında belirleyerek yola çıkmak gerçekçi olmayabilir. Bunun yerine 6 aylık dönemleri kapsayan bir yol haritası oluşturularak, her bir dönem sonunda teslimatı planlanan kapsam belirlenir. 6 aylık periyotların başlangıcında da o periyot içindeki iterasyonlar ve kapsamları planlanır. Sonraki 6 aylık periyodun kapsamıyla ilgili bu aşamada bir çalışma yapılmaz. Değişen öncelikler, yeni ortaya çıkan ihtiyaçlar çevik yaklaşımda planlarda da değişiklik yapılmasını gerektirebilir. Bu nedenle değişime açık olunması, bir planı sıkı sıkıya takip etmekten daha önemlidir.
Yazımın başında vurguladığım gibi maddelerin sağındaki ifadeler de yazılım projelerimizde var olmaya devam edecekler, bunlara da ihtiyaç var. Ancak tercihlerimizi ve önceliğimizi sol tarafa kaydırdığımızda yazılım projelerinde daha değer odaklı ve müşteri faydasını ön planda tutan, değişime açık bir yaklaşımı benimsemiş oluruz. Bunun da proje başarımıza doğrudan etkisi olacağını düşünüyorum. Unutmayalım, başarılı proje sözleşme gereklerini harfiyen yerine getiren proje değil, gerçekten sorun çözen ve fayda sağlayan projedir.
