İçeriğe geç

2.7 · Seviye 1 · Zemin

Yazılım krizinden Çevik Manifesto'ya

1968 NATO konferansından 2001 Snowbird buluşmasına yinelemeli geliştirmenin izini sürer

Proje Yönetimi Akademisi — M02, Proje Yönetiminin Tarihi · 1.616 kelime · ≈ 7 dk okuma · 11 dk dinleme

Sahnelerdeki kişiler, firmalar ve projeler kurgusaldır; araştırmalar, standartlar ve kaynaklar gerçektir. Akademi PMI, Scrum.org, Scrum Alliance ya da PeopleCert onaylı bir program değildir; mevzuat içeren dersler hukuki danışmanlığın yerine geçmez.

Sahadan bir an

Perşembe öğle arası, fabrikanın bahçesindeki bank. Onur, geçen haftaki sunumdan sonra Royce'u araştırmaya başlamış; şimdi elinde başka bir soru var. Ilgın çayını yudumlarken dinliyor.

Onur: Şelale hikâyesinin yarısı efsaneymiş, tamam. Ama çevik nereden çıktı? Bize 2001'de birkaç yazılımcının bir dağ otelinde icat ettiği anlatıldı.
Ilgın: Haluk Bey'e sormuştum. "Adı 2001'de kondu, fikri çok daha eski" dedi.
Onur: Ne kadar eski?
Ilgın: Onu söylemedi. "Bir sonraki sunumunu yazmadan önce kendin bul" dedi.
Onur: Yine okumam gereken bir şey var yani.
Ilgın: Bu sefer birlikte okuyalım. Tablet projesi de zaten o fikirle yürüyor.

Onur'un öğrendiği hikâye bir yarı doğru: Çevik Manifesto gerçekten 2001'de, bir dağ otelinde yazıldı. Ama manifestonun savunduğu fikirlerin, yani işi küçük parçalarla, sık geri bildirimle ve yineleyerek yapmanın, kökleri çok daha eskiye gidiyor. Bu ders proje yönetiminin tarih modülünü kapatıyor: 1960'ların "yazılım krizi"ni, 2001'deki manifestoyu ve aradaki otuz yılı aşkın sürede küçük parçalarla çalışma fikrinin nerede yaşadığını gösteren araştırmayı ele alıyor.

Kavram

1960'ların sonunda bilgisayarlar hızla güçlendi, ama onlar için yazılan büyük programlar aynı hızla güvenilir olmadı. Projeler gecikti, bütçeler aştı, teslim edilen yazılımlar istenen işi yapmadı.

Krize verilen ilk cevaplardan biri, yazılımı da bir mühendislik projesi gibi, aşamalara bölünmüş, belgeye dayalı ve her aşamanın sonunda bir onayla ilerleyen bir süreçle yönetmekti. Geçen derste gördüğümüz doğrusal sıra bu cevabın bir parçasıydı. Ama aynı yıllarda, bazı mühendisler ve araştırmacılar başka bir yol da deniyordu: sistemi tek seferde değil, küçük parçalarla, her parçayı deneyip ondan öğrenerek geliştirmek. Bu ikinci yol, bir azınlık geleneği olarak, onlarca yıl boyunca birçok büyük projede kullanıldı.

1990'larda bu geleneğin içinden, birbirinden bağımsız olarak, adlandırılmış yöntemler çıktı: Uç Programlama, Scrum, DSDM ve başkaları. Hepsi aynı yöne bakıyordu ama farklı adlarla ve farklı ayrıntılarla. 2001'de bu yöntemlerin temsilcileri bir araya geldi ve ortak bir zemin aradı.

Ilgın'ın tablet projesi, bu iki geleneğin bir fabrikada nasıl yan yana durabildiğini gösteriyor. Tabletlerin satın alınması ve kablosuz ağın kurulması önceden planlanıyor, formun kendisi ise bir vardiyada denenip öğrenilerek gelişiyor. Bu, ne yazılım krizine verilen ilk cevaba ne de manifestoya tam olarak uyuyor; iki geleneğin ortasında, işin parçalarına göre kurulmuş bir yol.

Manifestonun önemi, yeni bir fikir icat etmesinde değil, dağınık bir geleneğe bir ad ve bir ortak dil vermesindedir. Beşinci derste meslek kuruluşlarının yaptığını, manifesto küçük ölçekte yaptı: birbirini bulan uygulayıcılar, ortak bir dili yazıya döktü. Manifestonun değerlerini ve ilkelerini standartlar modülünde ayrıntısıyla okuyacağız.

Yinelemeli çalışma yazılıma özgü bir fikir de değildir. Bir öğretmen, bir dönem projesini öğrencilerinden dönem sonunda tek seferde teslim almak yerine, her iki haftada bir küçük bir taslak isteyip geri bildirim verdiğinde aynı mantığı kullanır. Öğrenci yanlış yöne gidiyorsa bunu dönem sonunda değil, ilk taslakta öğrenir. Fikir eskidir; yazılım dünyası onu sistemleştirdi ve adlandırdı.

Perde arkası

Yinelemeli geliştirmenin ne kadar eski olduğunu gösteren en çok anılan çalışma, iki yazarın bu geleneğin tarihini çıkardığı makaledir.

Manifestonun kendi web sitesi, toplantının hikâyesini katılımcılardan birinin kaleminden anlatır.

Highsmith'in metnindeki bir ayrıntı, manifestonun nasıl doğduğunu iyi anlatıyor: katılımcılardan biri, bu grubun önemli bir konuda anlaşabileceğini hiç beklemediğini, toplantının sonunda ise herkesin aynı ifadeden memnun olmasına şaşırdığını söylüyor. Manifesto, rakip yöntemlerin ortak paydasıydı; bir yöntemin zaferi değil.

Yaygın yanılgılar

Yaygın yanlış"Çeviklik 2001'de bir grup yazılımcı tarafından icat edildi."
Doğrusu

2001'de icat edilen şey, bir ad ve bir ortak metindir. Küçük parçalarla, geri bildirimle ve yineleyerek geliştirme fikri, Larman ve Basili'nin gösterdiği gibi 1950'lerin ortasından beri uygulanıyordu; manifestoyu imzalayanların temsil ettiği yöntemler de 1990'larda zaten vardı. Manifestoyu bir başlangıç noktası saymak, ondan önceki onlarca yıllık deneyimi görünmez kılar.

Yaygın yanlış"Çevik Manifesto belgeyi, planı ve süreci reddeder."
Doğrusu

Manifesto değerleri karşılaştırarak yazılmıştır ve sağdaki öğelerin de değerli olduğunu açıkça söyler; yalnızca soldakileri daha çok önemser. Belgeyi, planı ya da süreci reddetmez. Bu yanlış okuma, manifestonun en sık kötüye kullanılan yönüdür ve ileride kargo kültü çevikliği konuşurken ona döneceğiz.

İki sürüm

Ilgın ve Onur, bilgi işlemin bir sonraki sunumu için çevikliğin tarihini anlatan tek bir sayfa hazırlıyor. İlk taslak Onur'dan, ikincisi birlikte.

Zayıf sürüm

Başlık: Çevik devrim
Tarih: 2001'de 17 yazılımcı şelaleyi yıktı ve çevikliği icat etti.
Mesaj: Eski usul belgeler ve planlar bitti.

Güçlü sürüm

Başlık: Çevikliğin uzun tarihi
1950'lerin ortası ve sonrası: Büyük projelerde yinelemeli ve artımlı geliştirme kullanılıyor, ama azınlık bir gelenek olarak.
1968: "Yazılım krizi" adı yaygınlaşıyor; büyük yazılım projelerinin gecikmesi ve aşması bir mühendislik sorunu olarak tartışılıyor.
1990'lar: Uç Programlama, Scrum, DSDM gibi adlandırılmış yöntemler ortaya çıkıyor.
2001: Bu yöntemlerin temsilcileri ortak bir metinde, Çevik Manifesto'da, uzlaşıyor; manifesto belgeyi ve planı reddetmiyor, öncelikleri sıralıyor.

Zayıf sürüm, Onur'un öğrendiği hikâyeyi bir devrim anlatısına çeviriyor: bir tarih, bir yıkım, bir icat. Üç satırın üçü de geçen derste düzelttikleri hataya benziyor: bir yöntemin hikâyesini kaynağına bakmadan, çarpıcı bir cümleyle anlatmak. "Eski usul belgeler ve planlar bitti" cümlesi de manifestonun kendisiyle çelişiyor. Güçlü sürüm aynı tarihi bir zaman çizgisi olarak veriyor ve 2001'i bir başlangıç değil, uzun bir yolun adlandırma anı olarak konumlandırıyor. Son satırdaki "reddetmiyor, öncelikleri sıralıyor" ifadesi, manifestonun en sık yanlış okunan yanını baştan düzeltiyor. Güçlü sürüm daha az heyecanlı, ama dinleyiciyi bir sonraki efsaneden koruyor.

Bağlam notu

Tarihin bu modülü bir uyarıyla kapanıyor: yöntemlerin tarihi çoğu zaman bir yöntemi savunmak için anlatılır. Çevikliği savunan biri şelaleyi bir karikatüre çevirir; şelaleyi savunan biri çevikliği bir moda gibi anlatır. Larman ve Basili'nin tarihçesi bile, yazarlarından birinin yinelemeli geliştirmenin savunucusu olduğu bir bakış açısıyla yazılmıştır.

Neyle bileceğiz? Bir yöntemin tarihini okurken, anlatanın hangi yöntemi savunduğunu sormak, anlatıyı dengelemenin ilk adımıdır. İkinci adım, birincil kaynaklara, yani makalelerin, bildirilerin ve manifestonun kendi metnine bakmaktır. Bu modülde her derste bunu yapmaya çalıştık; ulaşamadığımız yerde, Royce'un makalesinde olduğu gibi, bunu açıkça söyledik. Bir sonraki modülde yöntemleri bir tarih olarak değil, bir yelpaze olarak karşılaştıracağız.

Uygulama

Retro sorusu

Pilot projende kullandığın yöntemlerden birini, kimin hangi amaçla anlattığını bilmeden mi benimsedin?

Kapanış

  1. "Yazılım krizi" 1960'ların sonunda büyük yazılım projelerinin gecikme ve aşma sorununa verilen addır ve yazılım mühendisliği çabalarının çıkış noktası oldu.
  2. Yinelemeli ve artımlı geliştirme 1950'lerin ortasından beri vardı; 1990'ların yöntemleri onu sistemleştirdi, 2001'de Çevik Manifesto ona bir ad ve ortak dil verdi.
  3. Yöntemlerin tarihi çoğu zaman bir yöntemi savunmak için anlatılır; anlatanın bakış açısını sormak ve birincil kaynağa gitmek anlatıyı dengeler.

Beş soru

  1. Onur'a anlatılan "çeviklik 2001'de icat edildi" hikâyesi neden bir yarı doğrudur?
  2. "Yazılım krizi" hangi sorunu adlandırıyordu?
  3. Larman ve Basili'ye göre yinelemeli geliştirme uygulamalarının ortak teması neydi?
  4. Bir sivil toplum kuruluşu, yeni bir gönüllü eğitim yöntemini "dünyada ilk kez bizim geliştirdiğimiz bir yaklaşım" diye tanıtıyor. Ne sorarsın?
  5. Güçlü sürümdeki "reddetmiyor, öncelikleri sıralıyor" ifadesi hangi yanlış okumayı önlüyor?

Yanıtlar

  1. Çünkü 2001'de icat edilen şey bir ad ve ortak bir metindir; küçük parçalarla ve yineleyerek geliştirme fikri 1950'lerin ortasından beri uygulanıyordu ve manifestoyu imzalayanların temsil ettiği yöntemler 1990'larda zaten vardı.
  2. 1960'ların sonunda yazılım geliştirmenin donanımdaki ilerlemeye ayak uyduramamasını; büyük yazılım projelerinin sık sık gecikmesini, bütçeyi aşmasını ve beklenen kaliteye ulaşamamasını.
  3. Tek geçişli, sıralı, belge güdümlü ve kapı kapı ilerleyen bir yaklaşımdan kaçınmak. Çekici yanlış cevap "belge yazmamak" olurdu; ortak tema belgeyi değil, tek geçişli sıralı ilerlemeyi hedef alıyordu.
  4. Bu yaklaşımın benzerleri daha önce başka yerlerde kullanılmış mı? Hangi geleneğe ya da yönteme dayanıyor? Anlatan kuruluş bu yöntemi hangi amaçla, örneğin bir hibe başvurusu ya da bir eğitim satışı için, tanıtıyor? Yeni olduğu iddiası, çoğu zaman bir adlandırmanın yeniliğidir.
  5. Manifestonun belgeyi, planı ve süreci reddettiği yanlış okumasını. Manifesto sağdaki öğelerin de değerli olduğunu söyler; yalnızca soldakileri daha çok önemser.

Sonraki derse köprü

Tarih modülü burada bitiyor: büyük yapıların defterlerinden kritik yola, sistem yönetiminden manifestoya. Ama tarih bize hangi yaklaşımın ne zaman kullanılacağını söylemez. Bir sonraki modül yaklaşımları bir yelpaze olarak karşılaştırıyor ve 3.1, yelpazenin bir ucundan, öngörücü yaklaşımın işe yaradığı koşullardan başlıyor.

Anlamadığın bir yer mi var?

Mentor yalnız bu dersin metnine dayanarak cevap verir. Metinde geçmeyen bir şey sorarsan uydurmaz, geçmediğini söyler.