DSDM: zamanı sabitleyip kapsamı esneten çevik proje çerçevesi
DSDM'in bir proje yönetim çerçevesi olarak nasıl çalıştığını, hangi ilkelere dayandığını, evrelerini ve rollerini ve zaman kutusu ile MoSCoW'un neden birlikte kullanıldığını öğrenirsiniz.
Bir bakışta
- DSDM, ürün geliştirme ile proje yönetimini tek süreçte birleştiren çevik bir çerçevedir. Çoğu çevik yaklaşımdan farklı olarak proje odağını, rolleri ve yönetim ürünlerini de tanımlar.
- Zaman, maliyet ve kalite sabitlenir; esneyen şey kapsamdır. Sorun çıktığında düşük öncelikli gereksinimler ertelenir ya da çıkarılır.
- Sekiz ilke yöntemin zihniyetini kurar. İlkelerden biri ödünsüz kaliteyi, biri zamanında teslimi, biri iş ihtiyacına odaklanmayı ister.
- Temeller evresinde yalnız yeterli ön tasarım yapılır. Geniş ama sığ bir çerçeve kurulur; ayrıntılar evrimsel geliştirme sırasında netleşir.
DSDM nedir?
DSDM, Dynamic Systems Development Method'un kısaltmasıdır; Türkçede Dinamik Sistem Geliştirme Yöntemi diye anılır. Hızlı uygulama geliştirme yaklaşımına kalite ve disiplin kazandırmak isteyen proje uygulayıcıları tarafından oluşturulmuştur ve yıllar içinde bugünkü DSDM Agile Project Framework'e evrilmiştir. Çerçevenin el kitabı Agile Business Consortium tarafından yayımlanır ve ücretsiz erişilebilir.
DSDM'in belirgin özelliği, ürün geliştirme ile proje yönetimini tek bir süreçte birleştirmesidir. El kitabına göre birçok kurum için DSDM tek başına yeterlidir; bazıları ise onu PRINCE2 ya da PMI gibi proje yönetim yöntemleriyle veya XP gibi yazılım mühendisliği uygulamalarıyla birleştirir. Çerçeve yazılımla sınırlı değildir; iş değişimi projelerinde de kullanılabilir.
Yaşam döngüsü: altı evre
DSDM süreç modeli altı evreden oluşur: proje öncesi, fizibilite, temeller, evrimsel geliştirme, dağıtım ve proje sonrası. Dört ana evrenin başında proje öncesi gelir, sonunda proje sonrası.
Fizibilite evresi, önerilen projenin teknik olarak yapılabilir ve iş açısından maliyet etkin görünüp görünmediğini anlamaya yeter; amaç, daha fazla incelemeyi haklı kılıp kılmadığına karar vermektir. Temeller evresi, iş gerekçesini, olası çözümü ve geliştirmenin nasıl yönetileceğini ayrıntıya girmeden anlar; bu yüzden büyük projelerde bile kısa sürmesi beklenir. Küçük ve basit projelerde fizibilite ile temeller tek evrede birleştirilebilir. Asıl çözüm, evrimsel geliştirmede zaman kutuları içinde artımlı olarak üretilir ve sürekli test edilir; dağıtım ise çözümü canlıya taşır. Dağıtım beklenmedik bir sonuç verirse temellere geri dönülebilir.
Proje ayrıntıya girmeden temelini kurar, çözümü artımlı geliştirir
DSDM süreç modelinin evreleri
- Proje öncesiDoğru proje başlarNet bir hedef ve doğru kurulum
- FizibiliteYapılabilir mi?Teknik ve iş açısından kısa değerlendirme
- TemellerGeniş ama sığ çerçeveİş gerekçesi, çözüm ve yönetim yaklaşımı
- GeliştirmeEvrimsel geliştirmeZaman kutularında artımlı üretim ve test
- DağıtımÇözüm canlıya çıkarGerekirse temellere dönüş
- Proje sonrasıFayda izlenirKazanımların değerlendirilmesi
Sekiz ilke
DSDM'in felsefesi, en iyi iş değerinin net iş hedefleriyle hizalanan, sık teslim eden ve motive, yetkilendirilmiş insanların iş birliğinden doğduğu fikrine dayanır. Bu felsefeyi sekiz ilke taşır:
- İş ihtiyacına odaklan
- Zamanında teslim et
- İş birliği yap
- Kaliteden asla ödün verme
- Sağlam temellerden artımlı inşa et
- Yinelemeli geliştir
- Sürekli ve net iletişim kur
- Kontrolü göster
El kitabı, ilkelerden herhangi birinin ihmal edilmesinin yöntemin felsefesini zayıflattığını ve riski artırdığını vurgular. İlkeler bir seçenek menüsü değil, birlikte çalışan bir bütün olarak sunulur.
Zaman kutusu ve MoSCoW
Geleneksel kurguda kapsam sabittir. Proje rayından çıkınca genellikle kaynak eklenir ya da teslim tarihi ertelenir; baskı altında kalite de farkında olmadan esnemeye başlar. DSDM bu dengeyi tersine çevirir: zaman, maliyet ve kalite temeller evresinin sonunda sabitlenir, risk payı ise teslim edilecek özellikler değiştirilerek yönetilir.
Bunu mümkün kılan iki uygulamadır. Zaman kutusu, işi sabit bitiş tarihli dilimlere böler. MoSCoW ise gereksinimleri Must Have, Should Have, Could Have ve Won't Have this time diye sınıflar. Sorun çıkınca önce Could Have gereksinimler çıkarılır; Won't Have sınıfı ise bu dönemde teslim edilmeyeceği baştan kabul edilen işleri kayda geçirerek kapsamın sessizce şişmesini önler. El kitabına göre en önemli gereksinimler önce yapıldığı için en kötü senaryoda bile en az kullanılabilir alt küme teslim edilir.
DSDM esneyen şeyi süreden kapsama taşır
Sabit olan ve esneyen
Roller ve yeterli ön tasarım
DSDM, rollerin ve sorumlulukların açıkça tanımlandığı bir çerçevedir. İş tarafında iş sponsoru, iş vizyoneri, iş elçisi ve iş danışmanı yer alır; yönetim tarafında proje yöneticisi, teknik koordinatör ve takım lideri; çözüm tarafında ise çözüm geliştirici, çözüm test uzmanı ve iş analisti gibi roller görev alır. İş elçisi, bilgili iş insanlarının geliştirme ekibine dahil olmasını sağlar; bu, yöntemin iş birliği ilkesinin somut karşılığıdır.
Ön tasarım konusunda da net bir tutum vardır. DSDM yalnız yeterli ön tasarımı savunur: temellerde analiz ve tasarım projenin tamamını kapsar ama ayrıntıya inmez. Böylece büyük ön tasarımın kaskatı planı ile hiç ön tasarım yapmamanın riski arasında bir denge kurulur.
Eğitimlerde yeri
DSDM'in dili çoğunlukla Agile Project Management (AgilePM) eğitimlerinde karşınıza çıkar. Mindset'in Agile Project Management Foundation eğitimi bu çerçeveye odaklanan kısa bir kurstur. Çevik proje yönetimini rol, evre ve öncelik kavramlarıyla yapılandırılmış biçimde öğrenmek isteyen proje yöneticileri ve iş analistleri için uygun bir başlangıç noktasıdır.
İlgili Mindset programı
Agile Project Management Foundation
Sık sorulan sorular
DSDM bir yazılım geliştirme yöntemi midir?
Kökeni yazılım geliştirmeye dayanır ama el kitabı çerçevenin iş değişimi projelerini de kapsayacak biçimde yorumlandığını belirtir. Yazılım dışı projelerde de işlediği söylenir. Asıl farkı, geliştirme ile proje yönetimini aynı süreçte ele almasıdır.
DSDM'de kapsam neden sabit değil?
Çünkü süre, maliyet ve kalite bir kez sabitlendiğinde dışarıda kalan tek esneklik teslim edilen özelliklerdir. MoSCoW sınıflaması hangilerinin önce, hangilerinin gerekirse sonra yapılacağını baştan görünür kılar. Böylece sorun çıkınca kimin neyi feda edeceği tartışması yerine hazır bir sıra kullanılır.
Yeterli ön tasarım klasik analiz ve tasarımdan nasıl ayrılır?
Klasik şelale yaklaşımında analiz ve tasarım ayrıntıya kadar iner. DSDM'in temeller evresi tüm projeyi kapsar ama ayrıntıya girmez; gereksinimlerin ayrıntısı evrimsel geliştirme sırasında, iş tarafıyla birlikte netleşir.
MoSCoW'daki Won't Have gereksinimler silinir mi?
Hayır. Bu dönemde teslim edilmeyeceği kabul edilen gereksinimler öncelikli gereksinim listesinde kayıtlı kalır. Bu, kapsamın netleşmesine yardım eder ve işlerin sonradan gayriresmi biçimde geri dönmesini engeller.
DSDM başka yöntemlerle birlikte kullanılabilir mi?
El kitabı bunun mümkün olduğunu belirtir: kimi kurumlar DSDM'i PRINCE2 ya da PMI gibi proje yönetim yöntemleriyle, kimileri de XP gibi yazılım mühendisliği uygulamalarıyla birleştirir. Hangi birleşimin uygun olduğu kurumun bağlamına göre belirlenir.