Makale Özeti

Yazılım sektöründe 2000 yılından bu yana sayısız projede yer aldım. Projelerin akıbetleri her zaman sorunsuz teslimatla sonuçlanmadığı gibi bir çoğu daha başlamadan sona erdi. Her zaman suç yazılımcıların iyi bir performansla çalışmaması bahane edilerek yazılım ekiplerine atıldı. İyi yönetilemeyen projelerin sorumlusu her zaman yazılımcılar olmuştur. Yanlış yönetim modelinin seçilmesi veya modelin yanlış dizayn edilmesi tüm projenin çöpe atılmasını sağlayabilir. Bizler yazılımcılar olarak görevlerimizi yerine getirdiğimizi biliyor ve inanıyoruz. Fakat proje yöneticileri bunun farkında olmadan kendi suçlarını hala bizim üzerimize atmaya devam ediyor. Biraz sitemkar olsa da durum böyle. Bölümün ilerleyen satırlarında proje yönetim modelleri hakkında bilgi veriyor olmakla birlikte doğru proje yönetimi, serbest çalışma stratejileri, sağlıklı çalışma ortamı oluşturmak gibi püf noktalara da değiniyor olacağım.

Makale

E-Ticaret

Günümüzde hızla gelişen teknoloji veya kavramlardan birisi şüphesiz E-Ticaret’tir. Durum böyle olunca yazılım tarafında üzerine düşülen konulardan biriside bu oluyor. E-Ticaret tarafında hızla gelişen ve yükselişte olan siteler nedeniyle bu daha belirgin hale geliyor. Para kazanma hırsı, iyi bir ürün çıkartmak ve/veya bunu paket halinde satışa sunmak, prestij yapmak gibi istekleri çok hızlı bir şekilde karşılayabiliyor. Tabi bu saydıklarım tamamen doğru yazılım ve pazarlama taktikleri ile oluyor.

E-Ticaret her yazılımcıya basit ve bir o kadar da karmaşık gelen ve uzmanlık gerektiren bir konudur. Uzmanlığınız yoksa kervanı yolda dizmek gibi bir olayın içerisinde bulursunuz kendinizi. Kervanı yolda dizmek, bu tarz komplike yapılarda işe yarayan bir mantık değildir. Tüm operasyonları yönetmek, hataları daha oluşmadan veya oluşurken bulmak, maliyetleri en aza indirmek ve operasyonel gücünüzü otomatik olarak halletmek işin ilk kurallarındandır. Bunlar olmazsa olmazlardır.

E-Ticaret yazılımları ve operasyonları doğru yapılandırıldıklarında getirileri çok yüksek olan iş modelleridir. Kurumsal ve bireysel model olarak ikiye ayrılır.

  • B2B (Business to Business) : Müşterilerin, kurumsal müşteriler olması ve halka açık olmaması durumunda e-ticaret sistemine verilen isimdir. Bu model’de sistem üzerinden alışveriş yapan kullanıcılar firmanın bayilerinden, iş ortaklarından veya personelinden ibaret olacaktır.
  • B2C (Business to Customer) : Müşterilerin, her hangi bir şahıs veya kurumsal bir firma olabileceği durumlarda e-ticaret sistemine verilen isimdir. E-Ticaret sistemi üzerinden alışveriş yapan kişi veya kurumun kim olduğuna bakılmadan alışveriş yaptırılır. Tabi bu “kim olduğuna bakılmadan” durumu her zaman geçerli değildir. Yazdığımı kurallara göre olayın seyri değişebilir. E-Ticaret kavramı yazılımcı çevrelerinde çok kolayca yazılabilir ve yönetilebilir bir yapı olarak görülse de işin aslı öyle değildir. Yazılım üzerinde fazlasıyla detaylar bulunmaktadır. Kitabımızda bu detayları tüm açıklığıyla ele alıp püf noktalar üzerinde test ve örneklerle ilerliyor olacağız. İşe başlamadan önce proje yönetim süreçleri hakkında bilgi sahibi olmanız, hatta proje yönetimini konu alan kitapları referans olarak kullanmanız yararlı olacaktır. Bu bölümün ilerleyen konularında proje yönetim süreçleri ile ilgili genel bilgi ve tecrübe paylaşımında bulunacağım. Doğru şekilde seçilmiş olan proje yönetim modeli projenin selameti açısından önem arz etmektedir. Bu nedenle bu bölümü anlamanız projenizin tamamlanması ve kendi içinizde organize olabilmeniz için gereklidir.

Proje Yönetim Süreçleri

Giriş

Yazılım sektöründe 2000 yılından bu yana sayısız projede yer aldım. Projelerin akıbetleri her zaman sorunsuz teslimatla sonuçlanmadığı gibi bir çoğu daha başlamadan sona erdi. Her zaman suç yazılımcıların iyi bir performansla çalışmaması bahane edilerek yazılım ekiplerine atıldı. İyi yönetilemeyen projelerin sorumlusu her zaman yazılımcılar olmuştur. Yanlış yönetim modelinin seçilmesi veya modelin yanlış dizayn edilmesi tüm projenin çöpe atılmasını sağlayabilir. Bizler yazılımcılar olarak görevlerimizi yerine getirdiğimizi biliyor ve inanıyoruz. Fakat proje yöneticileri bunun farkında olmadan kendi suçlarını hala bizim üzerimize atmaya devam ediyor. Biraz sitemkar olsa da durum böyle. Bölümün ilerleyen satırlarında proje yönetim modelleri hakkında bilgi veriyor olmakla birlikte doğru proje yönetimi, serbest çalışma stratejileri, sağlıklı çalışma ortamı oluşturmak gibi püf noktalara da değiniyor olacağım. Kitabın içeriğine uygun olması açısından kendi projelerimiz üzerinden gidiyor olacağım. Bireysel çalışma mantığını daha iyi kavramanız açısından bu daha mantıklı. Ben üreteceğim projeyi waterfall diye adlandırılan şelale modeli üzerinden giderek modellemeyi tercih ediyordum. Fakat bu süreç inanılmaz uzun bir süre alıyor. Gereksinimleri belirle / analizi yap, yazılım / veritabanı tasarla, kodlamaya başla, test et, hata olan yerleri düzenle vs. Ama projenin sahibi ben olsam da bu projeyi başkası için yapıyor olabilirim, projeyi acil bitirip para kazanmak istiyor olabilirim ve en önemlisi proje sürecinin uzaması motivasyonumu düşüreceği için projeyi tamamen veya parça parça görmek isteyebilirim. Şelale modelinde zaten gereksinimleri belirlerken motivasyon kaybı yaşanmakta. Bunun yanı sıra her durumu o anda analiz etme gibi bir şansınız yok. Daha sonra aklınıza gelen bir özelliği projenize dahil etmek isteyebilirsiniz. Analizi ve tasarımı bitirdikten sonra her hangi bir özellik eklemek istediğinizde tüm analizi ve tasarımı gözden geçirmek veya yeniden yapmak zorunda olacaksınız. Şelale modelinde öne çıkan diğer bir sorun ise süre belirlemedir. Bir müşterinizden e-ticaret işi aldınız, ücret konusunda anlaştınız. Bu aşama sonrasında müşteri “Ne kadar sürer ? ” sorusu ile sizi bunalıma itecektir. Siz şelale modelini baz alarak, “Analizi 10 günde bitirsem, tasarımı 5 günde yaparım, kodlamada 2 ay sürer, testleri 1 hafta desek, hatalar ve istekler içinde ekstra 1 ay daha koyayım” düşüncesiyle ortalama 3-4 ay süre belirlersiniz. İşe başladığınızda durumun o kadar parlak olmadığını ve hesaplamalarınızın yetersiz olduğunu göreceksiniz. Tabi ki hesaplar doğru ve tutarlı da olabilir. Yaptığınız proje modelinde süre tahminleri yetersiz ise fazla mesai yaparak günde 5 saat çalışacağınıza 10 saat çalışmanız gerekebilir. Ben bu durumları fazlasıyla yaşadığım için bu kısmı lütfen kendinize not ediniz. Freelance çalışanlara öneriler başlığında bu konuyla ilgili bir dizi tecrübe aktarıyor olacağım. Çok çalışmayı kabullenerek çalışıyor çalışıyor ve çalışıyorsunuz. Proje için verdiğiniz süre tam zamanında oluyor ve zamanında yetiştirip artık yayına alıyorsunuz. Müşteri projeyi inceliyor ve size çalıştığınız süre kadar çalışmanızı gerektirecek bir liste yolluyor. Aman Allah’ım ! Analizi müşteri ile yaptınız oysa . Olamaz böyle bir şey. Ama müşteri ısrarla şimdi aklıma geldi. Ben anlamam para verdim burası böyle olacak veya yanlış anlamışsın benim istediğim bu değil gibi bir karşılıkla sizi alt ediyor. Sürekli aynı sorunları yaşamaktan sıkıldığım bir dönemde kendimi nasıl bu durumdan kurtarabilirim. Nedir bu sorunun çözümü diye araştırmaya başladım. Bu sorun çalıştığım şirkette büyük bir yer kaplıyordu. Personel mutsuz, insanlıkları ellerinden alınmış ve sürekli mesai kavramıyla baş başa terk ediliyorlardı. Yazılımcısın haliyle uzaydan geldin. İnsansın ama farklısın sen. Uyumaz, yorulmazsın. Mesai sana vız gelir . 2003 yılından bu yana denemediğim proje yönetim süreci kalmadı. En sonunda başında denemem gerektiği için kendimi heder ettiğim bir süreçle mutluluğu yakaladım. Çevik süreç ! Biraz meraklandırayım . Sözü fazla uzatmadan, kısaca en çok kullanılan diğer modellere göz gezdirip en son çevik model ile ilgili açıklamalara devam edeceğiz. Unutmadan bu kitabın konusu proje yönetimi ve Çevik süreçler olmadığından konunun detaylarına inmeden temellerini anlamanızı sağlayacağım.

Şelale Modeli (Waterfall)

Bu model yazılım sektöründe en yaygın kullanılan modellerden birisidir. Model süreci müşteriden isteklerin alınması ile başlar. Müşteriden alınan istekler analistlere iletilerek şelale modeline uygun bir tararımın çıkartılması istenir. Analistler aşağıda bulunan resimde ki sıraya tamamıyla bağlı kalarak modeli hazırlamaya başlarlar. Aşağıda ki şekil de şelale modeline bir örnek verilmiştir.

Şelale modeli

Şekilde görüldüğü üzere onaylama aşamasında tekrar analiz aşamasına dönülmektedir. Bu demek oluyor ki, her onay aşamasında müşteri onay vermez ve istekte bulunursa bu süreç yeniden dizayn edilecektir. Süreç bu aşamada sıkıntıya düşmektedir. Fakat plansız çalışmaktan iyi olacağı kesin bir şeydir dersek tamamen doğru olacaktır.

Şelale modelinde karşımıza bir takım sorunlar çıkmaktadır. Bunlar,

  • Müşteri isteklerinin alındığı aşamada müşteri isteklerini tamamen aktarsa bile projenin ilerleyen safhalarında proje özelliklerinde yeni bir özellik keşfedebilir. Bu durum analizi tamamen revize etmeyi gerektirebilir.
  • Yazılımcı ve müşteri arasında her hangi bir bağ olmadığından yazılımcı proje modeline göre yazılımı hazırlayıp ilgili kişiye teslim eder. Bu gibi durumlarda yazılım teslim süresi 1 ay ile N yıl arasında olabileceğinden müşteri bu aşamada bekler ve çıkan yazılımı incelediğinde isteklerinin yapılmadığı veya yetersiz olduğunu tespit eder. Oysa yazılımcı ile her aşamada iletişimde bulunsa bu sorunlar olmayacaktı.
  • Müşteri yazılımını ancak tamamıyla kodlandıktan sonra test edebilir. Bu süre içerisinde ihtiyaçlar gelişmiş olabilir ve yazılım yetersiz kalabilir. Müşteri artı ve eksileriyle yazılımı kabul etmek zorunda kalabilir.

Ek bir konu proje dokümanının oluşturulmasıdır. Proje dokümanı eş zamanlı olarak oluşur ve inanılmaz bir vakit kaybıdır. Kısaca şelale modeli için, “plansız çalışmaktansa bu model tercih edilebilir” söylemi kullanmak yersiz olmaz.

Arttırımsal Model

Arttırımsal model projenin küçük parçalara ayrılarak yapılması esasına dayanır. Projenin analizi yani gereksinimleri belirlendikten sonra arrtırımsal bazda ayrıştırma yapılır. Gereksinimler daha küçük parçalara bölünür ve projenin parça parça testine dayanarak ilerlemesi sağlanır. Şelale modeline oranla biraz daha esnek ve riski düşüktür. Aşağıdaki şekil de arttırımsal modelin işleyişine bir örnek verilmiştir.

Arttırımsal modeli

Bu modelde sıklıkla kullanılabilir fakat şelale modeliyle benzeş yönlerinden dolayı müşteri tarafında sıkıntı oluşturabilir.

Spiral Model

Bu modele helozonik model adı da verilebilir. Spiral yazılım geliştirme modeli temel olarak 4 bölümden oluşmaktadır. Bunlar, planlama, risk yönetimi, üretim ve kullanıcı değerlendirmeleridir. Planlama aşamasında projenin analizi yapılır ve her modül ayrıntısıyla dokümante edilir. Risk analizi aşamasında projenin ne kadar risk taşıdığı, hangi modüllerde sorun olabileceği gibi durumların risk analizleri yapılarak risk yönetimi sağlanır. Üretim kısmında projenin kodlanması gelir. Kullanıcı değerlendirmeleri, adından da anlaşılacağı gibi müşterinin son değerlendirmelerini içerir. Aşağıdaki şekil de spiral modelin işleyişine bir örnek verilmiştir.

Spiral modeli

Spiral model risk analizi ve prototipler üzerine kurulmuş bir modeldir. Her döngü başlamadan önce modül için risk analizi yapılır. Daha sonra risk analizi yapılmış olan modülün prototipi çıkartılır. Her döngü sonunda yeniden analiz yapılır. Risk analizleri, gereksinimler ve kısıtlamalar çıkartılır.

Spiral model için daha önce geliştirilmiş ve yeni projede kullanılacak olan modüller için kullanılması uygundur diyebiliriz.

Spiral modelin en büyük avantajlarından birisi risk analizlerinin yapılmasıdır. Bu sayede maliyet ve kalite kontrol altında tutulur. Fakat önemli bir dezavantajı vardır; Spiral model küçük projelerde kullanılamadığı gibi risk analizi üzerine uzmanlık gerektiren bir modeldir. Bu nedenle tercih edilen bir model olduğu söylenemez.

Agile Development (Çevik Geliştirme)

Agile Development, yazılım geliştirme süreçleri, 1970 itibariyle kullanılmaya başlanmıştır. 1990 yıllarında kullanımı hız kazanmış ve geçtiğimiz 10 yıl içerisinde Türkiye içinde olmak üzere dünya üzerinde başarılarını kanıtlayarak kullanım oranını arttırmış yazılım geliştirme modelidir. Agile Development, yazılım geliştirme modeli, tekrarlanan yazılım geliştirme modelleri baz alınarak geliştirilmiştir. Sık aralıklarla modül modül yazılım teslimatını ve müşteri memnuniyetini hedef alır.

Tarihçe

Uygulanabilir yazılım geliştirme süreci ilk olarak 1974’te Edmonds tarafından ortaya atılmıştır. Bu teoriden sonra bir çok yöntem çevik yazılım geliştirme modeli, zor uygulanan aşırı kuralcı olan waterfall modeline tepki olarak ortaya çıkmıştır. Waterfall zor uygulanan ve kuralcı model olması nedeniyle usta yazılım geliştiriciler tarafından yavaş ve tutarsız olarak nitelendirilmiştir. Bu nitelendirmeden sonra bir çok çevik süreç ortaya çıkmaya başlamıştır. 2001 yılında yazılımın önde gelen isimleri Snowbird Utah’ta buluşarak ortada dolaşan metodları ortak bir platforma toplamış ve ismine “Agile Development” adını vermişlerdir. Aynı kişiler “Agile Alliance” adını verdikleri bir organizasyon kurarak sistemin gelişmesine destek vermişlerdir. Çevik süreçler arasından öne çıkanlar, Extreme Programming, Clear ve Scrum olarak gösterilebilir. Bu toplantı sonrası bir manifesto yayınlanmıştır. Ayrıca maniftoya bağlı olarak “Agile Principles” (Çevik Prensipler) adında 12 maddelik bir liste ek olarak sunulmuştur.

Manifesto
  • Kişiler ve iletişim süreç ve araçlardan önce gelir.
  • Çalışır durumda olan yazılım detaylı dokümantasyondan önemlidir.
  • Müşteri ile beraber çalışmak sözleşmelerden ve anlaşmalardan önemlidir.
  • Değişikliklere ayak uydurmak bir planı takip etmekten önemlidir.

Yukarıda belirtilen manifesto http://www.agilemanifesto.org adresinde orjinal haliyle görülebilir. Altı çizili olanlar diğerlerine göre daha öncelikli olsa da diğerleri de bizim için önem taşımaktadır. Altı çizili olanlar diğerlerini her zaman bastırmalıdır.

Prensipler
  1. En önemli öncelik erken ve sürekli olarak kullanılabilir programlar oluşturmak ve müşteriyi tatmin etmektir.

    Bu prensip tamamen müşteri memnuniyetine odaklandırmak amacıyla yazılmış gibi düşünülebilir. Fakat ne kadar erken geri dönüş olursa sorunların çözümü ve kalite o kadar artar. Kalitenin artması ve sorunların erken çözümü müşteri memnuniyeti sağlar. Yazılım sektöründe işler büyük çoğunlukla somut olduğundan müşteri elle tutulur, gözle görülür bir ürün beklemektedir. Müşteriye ilk görmek istediği modülü kısa bir süre içerisinde verirseniz memnuniyet artar, geri dönüş ile yazılımda ki eksiklikler giderilir. Bu durumda müşteri isteklerini tam anlamıyla alacağı bir yazılımın sahibi olur.

  2. Yazılımın ne aşamada olduğuna bakılmadan talep edilen değişiklikler olumlu karşılanmalıdır. Çevik süreçler, değişiklikleri müşterinin rekabetteki avantajlarını korumakta kullanırlar.

    Klasik yazılım geliştirme süreçlerinde yazılımın analizi henüz kodlama başlamadan oluşturulur. Bu analiz ışığında yazılımcılar kodlamaya başlar ve yazılımı bu analiz dışına çıkmadan gerçekleştirirler. Durum böyle olunca müşteri herhangi bir istek yaptığında analiz dışına çıkılamayacağı için istek geri çevrilir. Oysa ki müşterinin bu isteği müşteriye piyasada rekabet üstünlüğü sağlayabilir. Bu durumda istek sözleşme olsa dahi projeye girmelidir. Bu prensipte bu sağlanmış oluyor. Müşteri istediği an proje içerisine istediği özelliği ekleyebilir. Eklenen özellik tüm yazılımın alt yapısını değiştirse bile bu değişiklikler yapılarak yazılım müşteri için en ideal konuma getirilir.

  3. Kısa sürelerde çalışır yazılımlar ortaya koyulmadır (Bu süreler genelde birkaç haftadan, birkaç aya kadar olan sürelerdir). Seçim, zaman diliminin kısa tutulması yönünde olmalıdır.

    Klasik süreçlerde müşteri yazılımı ancak tamamıyla bittiğinde görebilir. Agile development ile müşteri sık sık yazılım görme imkanına sahiptir. Yazılım çalışabilecek en küçük parçalara bölünerek müşteriye 1-4 hafta içerisinde sunulur.

  4. Müşteri ve programcılar proje süresince birlikte çalışırlar.

    Müşterinin isteklerini programcının dinlemesi kadar güzel bir şey yoktur. Arada birileri olmadan müşteri ne istediğini işi yapacak olan kişiye birinci ağızdan anlatır. İşin kalitesi bu şekilde daha fazla yükselecektir.

  5. Projelerin, motivasyonu yüksek bireyler tarafından yapılması sağlanmalıdır. İhtiyaç duydukları ortamı ve desteği vermeli ve bitirebileceklerine inanılmalıdır.

    Proje geliştirimenin ve başarıya ulaştırmanın birinci kurallarından bir tanesi yüksek motivasyon sahibi proje ekibidir. Proje ekibinin dinlenmiş ve sorunlarının çözüşmüş olması gerekmektedir. Motivasyonu yükselten en önemli faktör ise ekip elemanlarına inanmaktır. Ekip elemanlarına bireysel sorumluluk verip özgüvenlerini yenilemek/sağlamlaştırmak iyi bir yol olacaktır.

  6. Bilgi alışverişinde en doğru ve efektif yöntem takım içinde yüz yüze konuşmaktır.

    Çevik süreçler bilgi alışverişini yüz yüze yapmayı sağlamıştır. Yazılımcılar-Müşteri-Yönetici üçlemesinde herkes yüz yüze görüşür ve bilgiyi deforme etmeden aktarabilirler. Ayrıca konuşurken yüzümüzde oluşan ifadeler önem arz ettiğinden yanlış anlaşılmalar ortadan kalkar ve aradaki bağlar sıkılaşır.

  7. Çalışır durumda olan yazılım ilerlemenin ana göstergesidir.

    İstediğiniz kadar müşteriye biz çalışıyoruz diyin. Bunun bir anlam ifade etmediğini siz de müşteri de çok iyi biliyor. Proje sahibi her zaman ne alacağını bilmek ister. Bunu sık sık görmek takip etmek ister. En doğal hakkı budur. Müşteriye sık sık çalışır halde bir yazılım göstermek müşterinin içini rahatlattığı gibi ilerleyen zamanlar için yol haritasınıda çizmiş olarak karşımıza çıkacaktır.

  8. Çevik süreçler etkili yazılım yöntemlerini destekler. Müşteri, programcılar ve kullanıcılar sabit bir tempoda birlikte çalışabilmelidirler.

    Özellikle yazılımcılar için iyi olan bir maddedir. Fazla mesai kavramı bu madde ile yok edilmiş oluyor. Eğer müşteri 5 saat çalışıyorsa yazılımcı da 5 saat çalışıyor/çalışmalı demektir. Müşteri iletişimi kopardığı anda projenin çevik süreç ile yönetilmesi mümkün olmayacaktır. Çünkü müşteri odaklıdır. Fazla mesainin yok olması ile birlikte motivasyon ve performans yükselir.

  9. Devamlı teknik mükemmelliğe özen gösterilmesi ve iyi tasarım çevikliği kuvvetlendirir.

    Çevik yazılım süreçleri ile yönetilen projelerde kalite beklentisi en yüksek noktada olacaktır. Yazılımlar mevcut veya temin edilecek en iyi araç ve yazılımcılar ile birlikte geliştirilir. Yazılım kalitesinin artması için ne gerekiyorsa yapılır. Yazılım tasarımı sürekli revize edilerek en iyi sonuca ulaşması sağlanır. Çevik sürekler için dinamik sistemler demek bu prensiple mümkün oluyor.

  10. Sadelik-Basitlik esastır.

    Yapılan yazılımların mümkün olduğunca basit olması gerekmektedir. Kalite beklentisinin yüksek olması sebebiyle karmaşanın da önüne geçilmek istenmektedir. Mümkün olduğunca basit arayüzlerle (tasarımsal veya kullanım kolaylığı) yazılımın kullanılabilirliği sağlanmalıdır. Ayrıca yazılan kodların temizliği ve aynı standartlarda olmasıda bu sadeliğe girmektedir. Bu yüzden proje başlanmadan önce kod yazım standartları belirlemek en doğru seçenek olacaktır.

  11. En iyi mimariler, gereksinimler ve tasarımlar kendi kendine organize olabilen takımlardan çıkar.

    Çevik yazılım geliştiren takımlar kendi başlarına organize olma hakkına ve yetisine sahip takımlardır. Takımlar şirket büroksisini umursamadan kendi iş planlarını tasarlar ve uygularlar. İş paylaşımlarını kendi aralarında eşit bir şekilde yaparlar. Bireysel aralarında sıkça konuşur ve bilgi alışverişinde bulunurlar.

  12. Belirli zaman dilimlerinde takım daha nasıl efektif olabileceği konusunda kendini sorgular ve edindiği bilgiler ile çalışma tarzına adapte eder.

    Daha önce belirttiğim gibi çevik takımlarda bilgi alışverişi ve kendi başına organize olabilme çok önemlidir. Takım üyeleri sıkça bir araya gelerek daha önce karşılaştıkları sorunları ortaya koyarlar ve tartışırlar. Fikir alışverişinde bulunup çalışma tarzlarını yargılayıp doğru olanı bulurlar.

Agile Development, bir arada çalışan ekipler için uygun olan bir yapıdır. Tek başına çalışan bir yazılımcı için etkili olacaktır ancak freelance çalışan bir ekipte etkili olacağını söylemek pek mümkün olmayacaktır. Bu gibi durumlarda şelale veya diğer modelleri benimsemek daha yerinde olacaktır. Agile Development mimarları da bu konuda aynı şeyi söylemekten çekinmiyorlar.

Agile Development ile ilgili anlatılacak bir çok şey var. Agile Development konusu başlıca bir kitap olacağından piyasada mevcut kitapları araştırmanızı tavsiye ederim.