Çevik metodolojinin her yerde kullanıldığı bir dünyada yaşıyoruz. Ünlü teknoloji devlerinden küçük girişimlere kadar herkes ürünlerini geliştirmek için bu yöntemi kullanıyor. Çevik hakkında bilgi edinirken “şelale metodolojisi” terimiyle karşılaşmış olabilirsiniz.
Çevik kullanan çoğu proje yöneticisi, şelaleyi 2023 yılında artık bir amaca hizmet etmeyen, modası geçmiş bir metodoloji olarak değerlendiriyor. Peki bu gerçekten doğru mu?
Kıdemli bir ürün yöneticisi olarak hem Çevik hem de şelale konusunda bolca deneyimim var. Şelale metodolojisini savunmak adına, ne olduğunu, nasıl işlediğini ve ne zaman kullanılmasının uygun olduğunu ayrıntılı olarak ele alalım.
Şelale Proje Yönetimi Metodolojisi Nedir?
Şelale, geliştirme projelerini farklı aşamalara ayırarak ve her aşamayı sırayla ele alarak yönetme kavramını ifade eder.
Büyük iş parçalarını daha küçük parçalara ayırmak, insanların çok eski zamanlardan beri kullandığı bir kavram olsa da şelale metodolojisinin resmî “doğuşu” çok daha sonra gerçekleşti—1970 yılında, o dönemin önde gelen bilgisayar bilimcilerinden Dr. Winston W. Royce, bunu “Büyük Yazılım Sistemlerinin Geliştirilmesini Yönetmek” adlı kitabında açıkladı.
O zamandan beri, 2000'li yılların başında dünya Çevik yaklaşıma yönelmeye başlayana kadar yazılım şirketlerinin projelerini yönetme biçimi bu oldu.
Şelale Yöntemiyle Yazılım Geliştirme Yaşam Döngüsü (SDLC) Nasıldır?
Çevik metodolojinin yinelemeli ve artımlı yapısının aksine, şelale için SDLC'nin hem belirgin bir başlangıcı hem de sonu vardır. Yazılım oluşturma sürecinin tamamını beş farklı aşamaya veya kilometre taşına ayırır ve bir aşamadaki çalışma, önceki aşama tamamlanana kadar başlamaz. Görsel olarak şöyledir:
Çalışma bir aşamadan diğerine ilerler, ardından en alta ulaşır ve proje “tamamlanmış” kabul edilir—bu da görsel olarak şelaleye benzemesini sağlar (terim de buradan gelir).
Şimdi bu doğrusal yaklaşımın her aşamasına göz atalım ve ne anlama geldiklerini anlayalım.
1. Aşama: Gereksinimlerin Toplanması
Her şey, projeyle ilgili gereksinimlerin tüm paydaşlardan toplanmasıyla başlar. Gereksinimler aşamasında proje yöneticileri, işlevsel gereksinimlerden bütçeye ve risk planına kadar projenin her yönünü kapsayan kapsamlı ve son derece ayrıntılı bir belge oluşturur.
Have an account? Log In
2. Aşama: Çözüm Tasarımı
Proje ekibi, önceki aşamada toplanan gereksinimlere dayanarak çözümü oluşturmaya ve tasarlamaya başlar. Burada “tasarım” terimi; ürünün teknik yapısını (sistem tasarımı), ürünün görsel ve etkileşim tasarımını (Kullanıcı Arayüzü/Kullanıcı Deneyimi Tasarımı) ve fiziksel tasarımını (fiziksel bir ürünse) ifade eder.
3. Aşama: Uygulama
Asıl kodlama bu aşamada gerçekleşir. Geliştirme ekibinizin üyeleri, tasarım aşamasında oluşturduğunuz çıktılara dayanarak ürünü geliştirmeye başlar.
Proje kapsamınızı ve tasarımınızı sürekli değiştirmekte özgür olduğunuz Çevik yaklaşımın aksine şelale, tasarım belgesini takip edeceğinizi ve uygulama aşamasında ürününüzü “geliştirmeye” devam etmeyeceğinizi varsayar.
4. Aşama: Test
Yazılım mühendisliği ekibi ürünü geliştirmeyi tamamladığında proje planımızın bir sonraki aşamasına—teste—geçebiliriz. Ekibiniz ürününüzü olası hatalar, güvenlik açıkları veya kullanıcı deneyimi sorunları açısından kontrol etmeye başlar.
Test aşamasında, nihai ürünün işlevselliğinin ve tasarımının ilk iki aşamada oluşturduğunuz proje gereksinimleri belgeleriyle eşleşip eşleşmediğini de kontrol edersiniz.
5. Aşama: Dağıtım ve Yayın Sonrası Destek
Ekibinizin ürününüzdeki tüm önemli sorunları bulup düzelttiğini varsayarsak, ürünü yayımlamanın ve çözümünüzü müşterilerinize ve son kullanıcılarınıza sunmanın zamanı gelmiştir.
Programcılarınız artık müşteri geri bildirimlerini sürekli toplayarak, gerekli düzeltmeleri yaparak ve ürününüz için yeni yamalar ile güncellemeler yayımlayarak bakım aşamasına geçer.
İşte bu kadar, projeniz tamamlandı ve bir sonraki projeye geçebilirsiniz!
Öyleyse şelale yöntemini kullanmalı mısınız?
Eğer siz de Çevik düşünceye sahip bir proje yöneticisiyseniz (en azından öyle olduğunuzu varsayıyorum), bu metodolojinin modasının geçtiğini ve onu kullanmayı asla düşünmemeniz gerektiğini düşünüyor olabilirsiniz; ancak size (saygıyla) katılmıyorum ve şelale yaklaşımının aslında belirli proje türleri için daha iyi bir seçenek olduğunu savunuyorum.
Görüşümü kanıtlamak için sizinle birkaç örneği ele alayım.
Örnek Olaylar: Şelale Metodunun Uygulamadaki Hâli
Her karmaşık kavramda olduğu gibi, metodolojinin gerçek hayatta nasıl işlediğini anlamak için bazı somut örnekler faydalı olabilir. Bu nedenle, şelale yaklaşımının uygulamada nasıl işlediğini zihninizde netleştirmenize yardımcı olmak için gerçek projelere dayanan (kendi üzerinde çalışmış olabileceğim veya olmayabileceğim) birkaç örneği burada bulabilirsiniz.
Örnek 1: Mısır Hükûmeti İçin Bir Gümrük İşlemleri Platformu
Mısır gibi görece büyük bir ülkenin uluslararası ticaret ve gümrük işlemleri sistemlerini modernize etme ihalesini kazanmış bir şirketin parçası olduğunuzu düşünün.
Mısır hükûmetinin istediği şey, Mısır'ın çeşitli limanlarına giren tüm gemilerin manifestolarını (gemideki tüm kargo ve yolcular hakkında bilgi içeren bir gümrük belgesi) yönetecek bir liman otoritesi sistemidir.
Ayrıca, sizden ülkedeki tüm gümrük beyannamelerini (diğer adıyla SAD'ler veya tek idari belgeler) işleyecek başka bir ürün geliştirmenizi ve bu sistemi söz konusu ürünle doğrudan entegre etmenizi istiyorlar. Formun sıradan insanların doldurması oldukça karmaşık olduğundan, bunu onlar için otomatikleştirmenizi istiyorlar.
Mısır'da, ithal ettiğiniz malların türüne, miktarına ve diğer faktörlere göre oranları değişen karmaşık bir vergi ve gümrük vergisi sistemi bulunuyor. Sıradan vatandaşların bu oranlar hakkında hiçbir fikri olmadığından, Mısır hükûmeti uygulamanızın vatandaşların beyan ettiklerine göre her şeyi otomatik olarak hesaplamasını ve çevrim içi olarak kredi kartlarıyla ödeme yapmalarına olanak tanımasını istiyor.
Bu, devasa bir girişim gibi görünüyor, değil mi? Projenin uygulama ayrıntılarını kesinleştirirken yöneticileriniz (hatta belki Mısır hükûmeti bile) proje yöneticisi olarak size gelip bu projenin uygulamasını nasıl organize etmek istediğinizi soracak.
Bu senaryoda şelale yöntemini neden ve nasıl kullanmalısınız:
Ulusal bir hükûmet için geliştireceğiniz her şey büyük olasılıkla parlamentonun onayladığı bir yasaya veya karara dayanacaktır. Bu kararlar, projenin genel koşullarından (örneğin maliyeti ve zaman çizelgesi) her şeyin nasıl işleyeceğine ilişkin en küçük ayrıntılara kadar her şeyi içerecektir.
Bu, şelale yönteminin ilk aşamasındaki bir gereksinim belgesine benziyor ve öyle görünüyor, değil mi? Aslında öyle; bu aynı zamanda Çevik yazılım geliştirmede olduğu gibi uygulama ayrıntılarını, tasarımı ve gereksinimleri anlık olarak gerçekten değiştiremeyeceğiniz anlamına da geliyor.
Bir zamanlar böyle bir ürüne liderlik ediyordum. Bir gün, iş mantığında birkaç küçük değişiklik yaparak kullanıcı deneyimini önemli ölçüde iyileştirebileceğimizi fark ettik. Fikrimizi hemen bizimle birlikte çalışan gümrük idaresi temsilcisiyle paylaştık.
Ancak hayır dedi. Böyle bir teklifi reddetmenin kötü bir fikir olduğunu düşünebilirsiniz, fakat bunu neden yapamayacaklarına dair iyi bir gerekçesi vardı.
Yaptığımız küçük değişiklikler, hükûmetin belirli bir ürünün vergilerini hesaplamak için kullandığı formülün değiştirilmesi anlamına geliyordu. Formül yasayla sabitlenmişti; dolayısıyla onu değiştirmek, ulusal parlamentonun tamamını toplayıp bunun için oylama yapmak anlamına gelecekti.
More Articles
Örnek 2: Ingenuity Helikopterinin Uçuş Kontrol Sistemi
Ingenuity, NASA'nın 2021'de inşa edip Mars'a gönderdiği yüksek teknoloji ürünü helikoptere verdiği addır. İşte küçük dostumuzun görünüşü.
Şimdi, bu inanılmaz teknoloji ürününün yazılımını geliştirmekten sorumlu şanslı proje yöneticilerinden biri olduğunuzu düşünün. Özellikle ekibinizin helikopterin uçuşunu kontrol edecek kodu yazması gerekiyordu.
Bir hava aracı (özellikle de bir helikopter) için uçuş kontrol sistemi oluşturmak çok zordur. Uçuş sırasında hava aracınızla etkileşime giren tüm fizik yasalarını göz önünde bulundurmanız ve kanatların gerekli dönüş hızını, kanatların açısını ve milyonlarca başka şeyi hesaplamanız gerekir.
Ancak göreviniz daha da karmaşık. Helikopterinizin, Dünya'dakinden 100 kat daha az yoğun bir atmosfere sahip başka bir gezegenin yüzeyinin üzerinde uçması gerekecek.
Bu senaryoda şelale yöntemini neden ve nasıl kullanmalısınız:
Bana göre burada şelale geliştirme tek seçeneğiniz. Küçük bir şey (MVP'niz) geliştirip bunu kullanıma sunduğunuz, gerçek hayatta kullandığınız, geri bildirim topladığınız ve bu geri bildirimlere göre çözümünüzü kademeli olarak iyileştirdiğiniz Çevik proje yönetiminin aksine, böyle bir projede riskler çok yüksektir.
Ingenuity'nin hatalı bir MVP'sini yapıp onu 140 milyon mil uzaklıktaki Mars'a uçurmayı gerçekten göze alabilir misiniz? Buna razı olacak hiç kimse yoktur.
Bu nedenle, son sürümünü oluşturmanız ve onu kızıl gezegene uçacak bir rokete yerleştirecek güveni kazanmanızdan önce tüm sistemlerini titizlikle test etmeniz gerekecek.
Şelale Modeli Hâlâ Yaşıyor ve İyi Durumda!
Aslında, bu geliştirme yöntemi dünya genelindeki projelerin yarısında hâlâ kullanılıyor ve beklediğinizden çok daha popüler.
Çevik yaklaşımın, ürünleri çok daha erken kullanıma sunmalarına ve kullanıcılarının geri bildirimleri üzerine geliştirmelerine olanak tanıyarak birçok proje yöneticisi için dünyayı daha iyi bir yer hâline getirmiş olmasına rağmen, şelale yöntemi sınırlı esnekliğe ve hatalara karşı düşük toleransa sahip projelerde kullanabileceğiniz hâlâ oldukça değerli bir yöntemdir.
Şelale yöntemi hakkındaki yazımızı beğendiğinizi umuyorum. Çevik yaklaşım hakkında da biraz daha okumak isterseniz, şu önerilerde bulunabilirim:
- Çevik Ürün Yönetimi rehberimiz.
- Çevik Portföy Yönetimi için en iyi uygulamaların derlemesi.
- En iyi Çevik Ürün Yönetimi Araçları için derlediğimiz liste.
Bunlar, ürün ve proje yönetimi hakkında hazırladığımız birçok rehber ve makaleden yalnızca üçü. Daha fazlası için bültenimize abone olun.
