CodeGym /Java Blogu /Rastgele /Yazılım geliştirme metodolojileri hakkında bilmeniz gerek...
John Squirrels
Seviye
San Francisco

Yazılım geliştirme metodolojileri hakkında bilmeniz gereken her şey: yeni başlayanlar için trendler, ilkeler ve tuzaklar

grupta yayınlandı
Yazılım geliştirme karmaşık bir iş sürecidir. Bu, BT uzmanlarının optimizasyon, planlama ve maliyetlendirme dilini konuşmaları gerektiği anlamına gelir. Yönetim kavramlarını anlamak, hem işverenlere hem de geliştiricilere büyük bir avantaj sağlar ve işbirliğini bir sonraki seviyeye taşımaya yardımcı olur. Yazılım geliştirme metodolojileri hakkında bilmeniz gereken her şey: yeni başlayanlar için trendler, ilkeler ve tuzaklar - 1

Dikkat, yeni başlayanlar! Modeller, metodolojiler ve genel kafa karışıklığı

Başlamak için önemli bir açıklama yapmamız gerekiyor: yazılım geliştirme modelleri ve yazılım geliştirme metodolojileri ayrı ve farklıdır. Modeller bir sistemin nasıl davranacağını tahmin eder. Sistemin olması gerektiği gibi çalışması için metodolojiler gereklidir. Kafa karıştırıcı yazılım geliştirme modelleri ve metodolojileri, her BT acemisi için standart işletim prosedürüdür, dolayısıyla bu büyük bir gaf olarak görülmez. Modele bir örnek , doğrusal ilerlemesi, her aşama için hedeflerin net bir şekilde tanımlanması ve son tarihler üzerinde sıkı kontrolü olan klasik şelale modelidir . Diğer bir model ise spiral modeldir ., proje risklerinin erken tespiti ve hafifletilmesine odaklanan. Spiral gelişim küçük başlar, önce yerel sorunları çözer ve sonra daha karmaşık sorunlara doğru ilerler. Son olarak, başka bir model , proje yaşam döngüsünün her biri bir "mini projeye" benzeyen bir dizi yinelemeye bölündüğü yinelemeli ve artımlı geliştirmedir (IID) . Genel olarak bir model, yazılım geliştirme sürecinin bir açıklamasıdır . Ancak metodolojiler, atanan görevler üzerindeki işi kontrol etmek, değerlendirmek ve izlemek için kullanılan sistemlerdir.. Metodolojiler, geliştirme sürecindeki her adımı kontrol etmek için gerekli olan modern çağın sopası ve havucudur. Projenin yönüne, bütçesine ve nihai ürünün uygulanması için son tarihlere göre seçilirler. Dahası, metodolojiler, proje liderinin ve ekibinin mizacına göre seçilebilir. Hatta şirketin veya müşterinin felsefesine göre. En popüler yöntemlere bir göz atalım.

1. Saldırı

Scrum, çevik bir proje yönetimi yöntemidir. Kesinlikle zamanla sınırlı (genellikle 2-4 hafta) "sprintlere" veya kısa yinelemelere dayanır. Bu, toplantıların süresini en aza indirir, ancak sıklıklarını artırır. Her sprint, yinelemenin sonunda tamamlanacak görevlerin bir listesinden oluşur ve her birinin kendi "ağırlığı" vardır. Toplantılar sırasında ekip, ekip üyelerinin neler yaptığını, ne yapmayı planladıklarını ve hangi sorunların olduğunu tartışır. Scrum, planlama için bir biriktirme listesi kullanır. Bu yaklaşımda, ekiplerin genellikle bir saldırı ustası vardır. Bu kişi ekibin kesintisiz çalışmasına yardımcı olur ve ekip için rahat bir ortam oluşturur. Projede ayrıca ürün sahibi rolünde biri olacaktır. Bu kişi geliştirme başkanıdır, ürünü izler ve müşterinin istekleri ile ekibin ürettikleri arasındaki ana bağlantı görevini görür.

Artıları:

  • mümkün olan en düşük bütçeyle bir projeyi hızlı bir şekilde başlatma yeteneği;
  • ilerlemenin günlük olarak izlenmesi, sık proje demoları;
  • proje sırasında ayarlamalar yapma yeteneği.

Eksileri:

  • sabit bir bütçenin olmaması nedeniyle sözleşme yapmada yaşanan zorluklar;
  • deneyimsiz bir ekip için veya son tarihler veya bütçe yetersiz olduğunda işe yaramaz;
  • sprintler arasında sürekli değişiklik yapma yeteneği kafa karışıklığı yaratabilir.

Kimin için?

Bunun gibi bir sistem, ister bağımsız ister büyük şirketlerde var olan on kişiye kadar olan projeler için uygundur. Bu, takımın büyük miktarda işi ve onları değişmeye ve yeni pazar koşullarına uyum sağlamaya zorlayan uzun bir yaşam döngüsüne sahip olması durumunda uygundur.

2. Kanban

Kanban'ın en önemli özelliği proje yaşam döngüsünün görselleştirilmesidir.. İş öğelerini gerçekleştirmek için sütunlar oluşturulur. İş öğeleri ayrı ayrı ele alınır. Sütunlar şu gibi durumlarla işaretlenmiştir: Yapılacak, Devam ediyor, Kod gözden geçiriliyor, Test ediliyor, Bitti (tabii ki sütun adları değişebilir). Her ekip üyesinin hedefi, ilk sütundaki iş öğelerinin sayısını azaltmaktır. Kanban'ın yaklaşımı sezgiseldir ve sorunların nerede olduğunu anlamanıza yardımcı olur. Kanban'ın yapısı kesin ve geri alınamaz bir şekilde sabit değildir: projenin özelliklerine bağlı olarak doğaçlama sütunlar ekleyebilirsiniz. Örneğin, bazı ekipler, bir iş öğesini gerçekleştirmeden önce onun için tamamlanan kuralları tanımlamanız gereken bir sistem kullanır. Bu durumda, iki sütun eklenir: Belirtin (parametreleri belirtin) ve Uygulayın (çalışmaya başlayın).

Artıları:

  • planlamada esneklik. Ekip sadece mevcut işe odaklanır, bir görevin önceliği de tanımlanır;
  • görünürlük Tüm katılımcıların verilere erişimi olduğunda, küresel sorunların tespit edilmesi daha kolaydır;
  • geliştirme sürecine yüksek katılım. Görselleştirme süreçleri öz-örgütlenmeyi ve öz-kontrolü artırır.

Eksileri:

  • beşten fazla kişiden oluşan ekiplerle çalışmaz;
  • uzun vadeli planlama için tasarlanmamıştır;
  • Motivasyonu olmayan bir takım için uygun değil. Kanban'ın her iş öğesi için son teslim tarihi yoktur. Metodoloji gecikmeler için ceza öngörmez.

Kimin için?

Kanban, ekibin büyümek ve sonuçlara ulaşmak için motive olduğu şirketlerde harika çalışıyor. Zaten açık olmalı - bu küçük bir ekip için. Belki bir müfreze veya bir ekibin parçası bile.

3. Rasyonel Birleşik Süreç (RUP)

RUP metodolojisi yinelemeli bir geliştirme modeli kullanır. Her yinelemenin sonunda (2 ila 6 hafta sürer), ekip planlanan hedeflere ulaşmalı ve projenin geçici de olsa çalışan bir versiyonunu almalıdır. RUP, projenin dört aşamaya bölünmesini talep ediyor . Her aşamada, ürünün yeni nesli üzerinde çalışmalar gerçekleştirilir: başlangıç, detaylandırma, yapım ve geçiş. Bir aşamanın sonunda, bir proje kilometre taşına ulaşılır. Ekibin sonuçlarını değerlendirdiği an, projenin dönüm noktası olarak kabul edilebilir. Bu, metodolojinin, ana özelliklerin ilk aşamada yayınlandığını ve sonraki aşamalarda ilavelerin eklendiğini ima ettiği anlamına gelir.

Artıları:

  • hem müşteriden hem de iş sırasında ortaya çıkan değişikliklerden değişen görevlerle başa çıkmayı mümkün kılar;
  • ürünün sürekli iyileştirilmesini sağlar. Yinelemeler sırasında projeyi titizlikle değerlendirebilir;
  • riskleri işin erken aşamalarında belirlemeyi ve ortadan kaldırmayı ve ayrıca geliştirme kalitesini etkin bir şekilde kontrol etmeyi mümkün kılar.

Eksileri:

  • Bu metodoloji oldukça karmaşıktır ve küçük bir ekipte veya şirkette uygulanması zordur;
  • uzmanların görev belirleme becerisine bağlıdır;
  • gereksinimlerin aşırı dokümantasyonuna ihtiyaç duyar.

Kimin için?

Ürünün olabildiğince çabuk piyasaya sürülmesi gerektiğinde, açıkça belirlenmiş gereksinimleri ve iyi anlaşılmış riskleri olan büyük projeler. Nişinizi hızlı bir şekilde işgal etmek ve ancak daha sonra son rötuşları eklemek için işlevsellik pahasına bile.

Birçok metodoloji var, ancak bir trend

İnkar edilemez derecede popüler olan ve çevik ilkelere dayanan scrum ve Kanban'ın yanı sıra dayanıklı, yinelemeli RUP metodolojisine ek olarak, şirketler birçok farklı metodoloji kullanır. Bir şirket aşırı programlamaya ve en hızlı ve en basit kararları vermeye daha yakın olabilir. Bir diğeri, test odaklı geliştirmeye daha yakın olabilir. Bir başkası da hızlı uygulama geliştirmeyi (RAD) tercih edebilir. Bununla birlikte, aynı anda birden fazla metodolojiyi kullanmaya yönelik güçlü ve tartışılmaz bir eğilim var.. Veya modelleri ve metodolojileri benzersiz bir yönetim sisteminde birleştirmek. Günümüz şirketleri, sorumlulukları departmanlar ve organizasyonel birimler arasında kaydırmadan, bürokratik engelleri ortadan kaldırmaya ve organizasyon içinde birleşik bir ekip çalışması atmosferi yaratmaya çalışmaktadır. Scrum Alliance'a göre, BT şirketlerinin %70'i scrum kullanıyor. Bunlar arasında Google, Amazon, Salesforce, Microsoft ve Adobe gibi devler var. Startup'lar ve genç projeler Kanban'a daha yatkın ama Toyota ve örneğin Wargaming'deki oyuncular da Kanban'ı kullanıyor. Scrum bir planlama aracıdır, Kanban ise ilerlemeyi izlemek içindir. RUP ise en çok 50-200 çalışanı ve 1-10 milyon dolar geliri olan Batılı şirketler tarafından kullanılıyor. Ancak IBM, çevik ilkelere yaklaşmak için RUP'u değiştirerek OpenUP metodolojisini (RUP, ancak çevik) piyasaya sürdü. Bu övülen çevik metodoloji artık BT dünyasını yönlendiriyor . Bu sadece geçici bir heves değil, hala yenilikçi ve aslında birçok büyük şirkette kullanılıyor. Çevik Silikon Vadisi'nde kullanılır. Facebook ve Uber kullanıyor.

Alt çizgi

Her projenin ekibe, finansmana, son teslim tarihlerine ve müşteri gereksinimlerine bağlı olan kendi yazılım geliştirme metodolojisi vardır. Evrensel bir yönetim tekniği yoktur: Çılgınca popüler olan çevik metodoloji bile geliştirme sürecine en iyi yaklaşımı garanti edemez. Sonuç olarak, metodolojiler dikkatle, hatta bazen prensip olarak seçilir. Öyle ki metodolojisine bakarak bir şirketin kendisi veya müşterileri hakkında çıkarımlarda bulunabiliriz. Metodolojiler karıştırılır, modellerle desteklenir ve uyarlanır. Öyle ki yeni yaklaşımlar doğuruyorlar. Bununla birlikte, yönetim alanı, şelale modelinin beklenmedik unsurları veya yinelemeli RUP metodolojisi ile nihayetinde scrum ve Kanban'ın elinde kalır.
Daha fazla okuma:
Web siteleri: Kitabın:
  • Andrew Stelman, Jennifer Greene: "Çevik Öğrenme";
  • Per Kroll, Bruce MacIsaac: "Çeviklik ve Disiplin Kolaylaştırıldı: OpenUP ve RUP Uygulamaları";
  • Mike Cohn: "Agile ile Başarılı Olmak: Scrum Kullanarak Yazılım Geliştirme";
  • Robert C. Martin: "Çevik Yazılım Geliştirme: İlkeler, Modeller, Uygulamalar";
  • Marcus Hammarberg, Joakim Sunden: "Eylemde Kanban";
  • I. Jacobson, G. Booch, J. Rumbaugh: "Birleşik Yazılım Geliştirme Süreci".
Yorumlar
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION