Firmalar, yaptığı yatırımın geri dönüşünü alabilmek, pazara çıkma hızını arttırmak, rekabet avantajı sağlamak, değer yaratmak, kalitesini arttırmak ve değişebilmek gibi çok çeşitli nedenlerle projeler yaparlar.
Bu düşüncelerini projeyi gerçekleştirecek ekibe doğrudan yansıtamadıkları durumlarda, ekip beklentiyi iki ana başlık altında görür: Deadline ve Değişim.
“Konuştuğumuz tarihte reklama çıkıyoruz”, “Ne yaparsanız yapın bu projeyi zamanında bitirin” tarzı cümleler ekip üzerinde bir bitiş tarihi (deadline) baskısı oluşturur. Ekip bu tarih için söz verir elbette, ancak “Projede bazı değişiklikler yapmamız gerekiyor” cümlesi ile başlayan “Çünkü hayat değişiyor ve bu değişiklikleri projemize yansıtmamız lazım” şeklinde devam eden konuşmalar da hayatın bir gerçeği olarak ekibin karşısında durmaktadır.
Bu gerginlikleri ortadan kaldırmanın birinci koşulu, hem projeyi talep eden müşteri hem de gerçekleştiren ekip olarak öncelikle üretilecek değere odaklanılmasıdır. Bütçe ve zaman kısıtlamaları bunun ardından irdelenmesi gereken konulardır. Müşteri ihtiyaçlarını elde edilecek değere göre önceliklendirmelidir.
21. yüzyılda, içinde her şey olan değil, tek odağı olan ürünler üretilmeye başlandı. Hem herşeyi olsun hem de hızlı olsun fikrinin gerçekçi olmadığının farkına varıldı. Artık herşey bitince pazara çıkma düşüncesinin sonuna gelindi. Doğru önceliklerle piyasaya peyderpey çıkmak önemli artık.
Çalışmaları yaparken süreçlere çok fazla odaklandığımızda, ürünü göz ardı edebiliyoruz. Süreçlerin hemen her aşamasında son kullanıcıyı mutlaka dahil etmemiz gerekiyor.
Değer’den sonra gelen ikinci önemli faktör de değişime karşı davranışımız. Geçtiğimiz yıllarda değişime adapte olmanın önemi vurgulandı hep, ancak günümüzde artık değişimi nasıl yaratabilirim düşüncesi önem kazanmaktadır.
Değişimi gerçekleştirecek ve değer yaratacak projelerin doğasında belirsizlik yüksektir. Hem müşteri hem de ekip yönünden bu belirsizliği nasıl çözüleceği önemli bir problem olarak karşılarına çıkmaktadır. Belirsizlik ve karmaşıklığı çözmek için proje boyunca ilerlerken yön değiştirebilecek bir metoda ihtiyaç vardır.
Biraz geçmişe dönersek, 20. Yüzyılın başlarında, tarım toplumundan sanayi toplumuna geçen insanoğlu, Ford fabrikasında ilk seri üretimi deneyimlerken yei bir kavramla karşılaştı. İşi tanımlayan ve yapanın ayrıştırılması. Tarım toplumunda kişi, yüzlerce yıl önce ataları tarafından tanımlanmış ve içselleştirmiş olduğu tarım sürecini gerçekleştiriyordu. Oysa sanayide beyaz yakalı ve mavi yakalı olarak ikiye bölündü çalışanlar. Beyaz yakalı işi tanımlarken, mavi yakalı da tanımlanan işi yapmaya başladı. İşi yapanın edinimlerini paylaşması için bir ortam yoktur. Çünkü bakış açısı, kişinin kaytarma eğiliminde olduğu ve onun sıkıca kontrol altında tutulması gerektiğiydi. Hatta, işin istenilen kalitede yapıldığının kontrolü için Kalite Kontrol departmanları kurulmuştu.
Benzer yaklaşım, 80’lerin sonunda yaygınlaşmaya başlayan Yazılım Geliştirme dünyasında da ilk başlarda görülmeye başladı. Ancak dünya atrık sanayi toplumundan bilgi toplumuna evrilmeye başlamıştı. Artık işbirliği ön plana çıkmalıydı, ilişkiler güven üzerine oturmalıydı.
2001 yılında, 17 yazılım geliştirme uzmanı, yazılım geliştirme projelerinde üretkenliği arttırmak için iki günlük bir çalıştay gerçekleştirdiler. Çalıştayın sonunda 4 maddelik bir değerler topluluğu ortaya çıkarttılar.
- 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.
Bu maddelerden ilkinde bireyler ve arasındaki etkileşimlerin, süreç ve araçlardan daha önemli olduğuna, takım olmanın ve işbirliğinin önemine vurgu yapılmaktadır.
İkinci maddede çalışır durumdaki yazılım, detaylı dokümandan daha önemli olduğu işaret edilirken, hiç doküman yapılmaması kastedilmemekte, ancak kaynakların yüksek değer üretecek şekilde kullanması gerektiğinin altı çizilmektedir.
Üçüncü maddede müşterinin takımın bir parçası olduğu, e-mail ile , doküman ve toplantı ile müşterinin sürece dahil olamayacağına, çalışır durumda çıktı vermenin önemine dikkat çekilmektedir.
Son maddede de değişimi kucaklamanın planı körü körüne takip etmek ile çeliştiği belirtilmektedir.
“Agile” ya da Türkçe karşılığı ile “Çevik” bir felsefedir. Geçmişte dilimizde çok kullanılan ama bugün unutulmaya yüz tutmuş olan “İmece” kelimesi de aynı felsefeyi işaret etmektedir. Agile Manifesto’nun yazılım geliştirme uzmanları tarafından yayınlanmış olması bunun sadece mühendislik alanında kullanılacağı anlamına gelmemektedir. Yönetimsel alanlarda da Agile uygulamak mümkündür.
Mühendislik alanında Extreme Programming (XP), TDD (Test Driven Development), Feature Driven Develpment (FDD), Continuous Integration (CI) gibi yöntemler kullanılırken, yönetim alanında SCRUM, Nexus Scrum (Sacel Scrum), SAFE (Scaled Agile Framework), PMI-ACP (Project Management Institue – Agile Certified Practitioner) gibi çerçeveler mevcuttur. Onları da başka yazılarımızda irdeliyor olacağız.
Saygılarımla