Agile (Çevik) Yöntemler Neden Popüler Oldu? – 2

Çevik süreçler değişimi müşterinin rekabet avantajı için kullanır.

Fayda yaratacak değişimi işin içine sokmak, fayda yaratmayanı sırf istendiği için yapmamak ilkesi çok önemli. Oldukça mantıklı olan bu prensip BT departmanlarının gelen işleri sadece yapmakla yükümlü olması prensibini değiştiriyor. Şirketin, BT departmanını sadece maliyet merkezi değil, işi bilen ve geliştirici öneriler getirebilen bir yer olduğunu fark eden firmalarda BT Yöneticileri istenilen değişikliklerin yaratacağı faydayı sorgulayabiliyor, gerektiğinde red edebiliyorlardı.

Çalışan yazılım, tercihen kısa zaman aralıkları belirlenerek birkaç haftada ya da birkaç ayda bir düzenli olarak müşteriye sunulmalıdır.

Neredeyse 20 yıldır içinde olduğum Proje Yönetimi konusunda “belirsizliği yüksek projelerde sık sık onay almak gerekir” prensibini bilirim. Doğru yolda gittiğinin teyidi alarak ekip daha motive bir şekilde ilerleyebilir. Amaç yeniden iş yapmamak, her işi tek defada doğru yapmaktır. Çevik süreçler bunu yapısı itibari ile döngü içi işlere dönüştürerek sistemsel yapılabilmesini sağlayabiliyor. Geleneksel yöntemde aynısı planlama aşamasında düşünülerek yapılabilir.

İş süreçlerinin sahipleri ve yazılımcılar proje boyunca her gün birlikte çalışmalıdırlar.

Mutlak ifadeler (her gün) beni korkutmuştur. Projenin her aşamasında her gün bir araya gelmenin gerekliliğini tartışmalı buluyorum. Projenin yaşam çevrimini masaya yatırıp hangi süreçlerde her gün hangilerinde daha seyrek bir araya gelinmesi gerektiği ekipçe belirlenebilir. Sırf bir yönteme uymak adına çalışanları her gün toplantı yapmaya itmeyi doğru bulmuyorum. Analiz aşamasında yapalım, yazılımda hafta da bir yapalım gibi her proje özel ve ihtiyacı karşılayacak bir prensip belirlenmelidir.

Aşağıdaki yazıları da beğeneceksiniz:

Paylaşın:

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

18 + 6 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.