Artıları ve Eksileri ile Agile (Çevik) Yöntemler

Artıları ve Eksileri ile Agile (Çevik) Yöntemler

Agile (Çevik), ekiplerin müşterilerine daha hızlı ve daha az baş ağrısı ile değer vermelerine yardımcı olan proje yönetimi ve yazılım geliştirmeye yönelik yinelemeli bir yaklaşımdır. "Büyük patlama" lansmanında her şeyi almak yerine, çevik bir ekip küçük ama kullanılabilir ilerlemeler sağlar. Gereksinimler, planlar ve sonuçlar sürekli olarak değerlendirilir, böylece ekiplerin hızlı bir şekilde değişime cevap vermek için doğal bir mekanizması vardır.

Agile (Çevik) nedir?

Çevik yazılım geliştirme, artımlı, yinelemeli (sprint) bir yaklaşıma dayanmaktadır. Projenin başlangıcında derinlemesine planlama yerine, Agile metodolojileri zaman içinde değişen gereksinimlere açık olup son kullanıcılardan gelen sürekli geri bildirimleri teşvik etmektedir. Fonksiyonlar arası ekipler, bir ürünün iterasyonları üzerinde belirli bir süre çalışırlar ve bu iş, iş veya müşteri değerine göre önceliklendirilen bir yığılma olarak düzenlenir. Her yinelemenin amacı, çalışan bir ürün üretmektir.

Çevik metodolojilerde, liderlik ekip çalışmasını, hesap verebilirliği ve yüz yüze iletişimi teşvik eder. İş paydaşları ve geliştiriciler, ürünü müşteri ihtiyaçları ve şirket hedefleri ile uyumlu hale getirmek için birlikte çalışmalıdır.

Çevik, Agile Manifesto'nun kavramlarıyla uyumlu herhangi bir sürece atıfta bulunur. 2001 yılının Şubat ayında, 17 yazılım geliştiricisi Utah'da hafif gelişim yöntemlerini tartıştılar. “ Yazılım geliştirmenin daha iyi yollarını kullanarak ve başkalarına yardımcı olarak nasıl kullandıklarını” anlatan Agile Yazılım Geliştirme Manifestosu'nu yayınladılar ve dört değer ve 12 ilke dahil ettiler. Çevik Manifesto, geleneksel Proje Yöneticisinin Bilgi Gövdesi ( Project Manager’s Body of Knowledge ) rehberi ve standartlarına çarpıcı bir tezat oluşturmaktadır.

Çevik Yazılım Geliştirme Manifestosu

Bizler daha iyi yazılım geliştirme yollarını uygulayarak ve başkalarının da uygulamasına yardım ederek ortaya çıkartıyoruz.

Bu çalışmaların sonucunda:

  • Süreçler ve araçlardan ziyade bireyler ve etkileşimlere
  • Kapsamlı dökümantasyondan ziyade çalışan yazılıma
  • Sözleşme pazarlıklarından ziyade müşteri ile işbirliğine
  • Bir plana bağlı kalmaktan ziyade değişime karşılık vermeye değer vermeye kanaat getirdik.

Özetle, sol taraftaki maddelerin değerini kabul etmekle birlikte, sağ taraftaki maddeleri daha değerli bulmaktayız.

Çevik Metodolojinin 12 İlkesi

Çevik Manifesto, takımları çeviklikle nasıl başa çıkılacağı konusunda yönlendirmek için 12 ilkeyi listeler. Bunlar prensipler:

  • 1. En önemli önceliğimiz değerli yazılımın erken ve devamlı teslimini sağlayarak müşterileri memnun etmektir.
  • 2. Değişen gereksinimler yazılım sürecinin son aşamalarında bile kabul edilmelidir. Çevik süreçler değişimi müşterinin rekabet avantajı için kullanır.
  • 3. Ç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.
  • 4. İş süreçlerinin sahipleri ve yazılımcılar proje boyunca her gün birlikte çalışmalıdırlar.
  • 5. Projelerin temelinde motive olmuş bireyler yer almalıdır. Onlara ihtiyaçları olan ortam ve destek sağlanmalı, işi başaracakları konusunda güven duyulmalıdır.
  • 6. Bir yazılım takımında bilgi alışverişinin en verimli ve etkin yöntemi yüzyüze iletişimdir.
  • 7. Çalışan yazılım ilerlemenin birincil öçüsüdür.
  • 8. Çevik süreçler sürdürülebilir geliştirmeyi teşvik etmektedir. Sponsorlar, yazılımcılar ve kullanıcılar sabit tempoyu sürekli devam ettirebilmelidir.
  • 9. Teknik mükemmeliyet ve iyi tasarım konusundaki sürekli özen çevikliği artırır.
  • 10. Sadelik, yapılmasına gerek olmayan işlerin mümkün olduğunca arttırılması sanatı, olmazsa olmazlardandır.
  • 11. En iyi mimariler, gereksinimler ve tasarımlar kendi kendini örgütleyen takımlardan ortaya çıkar.
  • 12. Takım, düzenli aralıklarla nasıl daha etkili ve verimli olabileceğinin üzerinde düşünür ve davranışlarını buna göre ayarlar ve düzenler.

Çevik yöntemin avantajları

Çevik, 1990'larda farklı hafif yazılım yaklaşımlarından yola çıkarak; katı, doğrusal Şelale (waterfall) metodolojisinden hoşlanmayan bazı proje yöneticilerinin bir yanıtıydı. Esneklik, sürekli iyileştirme ve hıza odaklanır.

İşte Agile'nin en büyük avantajlarından bazıları:

  • Değişim benimsenir : Kısa planlama döngüleri ile, proje sırasında herhangi bir zamanda değişiklik yapmak ve kabul etmek kolaydır. Ekiplerin haftada bir kez projede değişiklik yapmasına izin vermek için, biriktirmeyi yeniden düzenleyip yeniden konumlandırmak için her zaman bir fırsat vardır.

  • Bitiş hedefi bilinemeyen projeler : Çevik, nihai hedefin açıkça tanımlanmadığı projeler için çok faydalıdır. Proje ilerledikçe hedefler ortaya çıkacak ve gelişim bu gelişen gereksinimlere kolayca adapte olabilecektir.

  • Daha hızlı, yüksek kaliteli çıktılar : Projeyi tekrar tekrar devreye almak (yönetilebilir birimler), ekibin yüksek kaliteli geliştirme, test etme ve işbirliğine odaklanmasını sağlar. Her yineleme (sprint) sırasında test yapmak, hataların daha hızlı tanımlanmasını ve çözülmesini sağlar. Ve bu yüksek kaliteli yazılım tutarlı, art arda yinelenen adımlarla daha hızlı teslim edilebilir.

  • Güçlü takım etkileşimi : Çevik, sık iletişimin ve yüz yüze etkileşimlerin önemini vurgulamaktadır. Takımlar birlikte çalışır ve insanlar projelerin sorumluluğunu ve kendi parçalarına düşeni üstlerine alabilirler.

  • Müşteriler dinlenir: Müşterilerin teslim edilen işi görmeleri, girdilerini paylaşmaları ve son ürün üzerinde gerçek bir etkisi olması için birçok fırsatı vardır. Proje ekibiyle çok yakın çalışarak sahiplik duygusu kazanabilirler.

  • Sürekli iyileştirme : Çevik projeler, tüm proje boyunca kullanıcılardan ve ekip üyelerinden geri bildirim almayı teşvik eder, böylece öğrenilen dersler, gelecekteki iterasyonları iyileştirmek için kullanılır.

Çevik yöntemin dezavantajları

Çevik'teki esneklik seviyesi genellikle pozitif olsa da, aynı zamanda bazı sorunlara da yol açabilir. Katı bir teslimat tarihi belirlemek zor olabilir, dokümantasyon ihmal edilebilir veya nihai ürün orjinal olarak tasarlanandan çok farklı olabilir.

İşte Agile'nin dezavantajlarından bazıları:

  • Planlama daha az sabit olabilir: Bazen vazgeçilemez bir teslimat tarihini sabitlemek zor olabilir. Agile belirli süreli yinelemeli çıktılara dayalı olduğundan ve proje yöneticileri genellikle görevleri tekrarlamakta olduğundan, başlangıçta teslimat için planlanan bazı öğelerin zamanında tamamlanamaması mümkündür. Ayrıca, projenin herhangi bir anında yeni bir sprint eklenebilir ve bu da nihai hedef süreyi uzatacaktır.

  • Takım bilgili olmalıdır: Çevik takımlar genellikle küçüktür, 8-10 kişi civarında olması tercih edilir. Bu yüzden takım üyeleri çeşitli alanlarda çok yetenekli olmalıdırlar. Ayrıca seçilen Agile metodolojiyi anlamalı ve rahat hissetmelidirler.

  • Yazılım geliştiricilerden zaman taahhüdü: Çevik, geliştirme ekibi tamamen projeye adanmış olduğunda en başarılı olanıdır. Geleneksel bir yaklaşımdan daha fazla zaman alan Çevik süreç boyunca aktif katılım ve işbirliği gereklidir. Ayrıca, bu geliştiricilerin projenin tüm süresine bağlı kalmaları gerektiği anlamına gelir.

  • Belgeler ihmal edilebilir: Agile Manifesto, kapsamlı bir dokümantasyon yerine çalışma yazılımını tercih eder, bu nedenle bazı ekip üyeleri, dokümantasyona odaklanmayı daha az önemli gibi hissedebilirler. Kapsamlı dokümantasyon, proje başarısına yol açmamakla birlikte, Çevik takımlar dokümantasyon ve tartışma arasındaki doğru dengeyi bulmalıdır.

  • Nihai ürün çok farklı olabilir: Çevik projeler ilk başlarda kesin bir plana sahip olmayabilir, bu nedenle nihai ürün başlangıçta tasarlanandan çok farklı görünebilir. Agile çok esnek olduğu için, değişen müşteri geri bildirimlerine dayanarak yeni iterasyonlar eklenebilir, bu da çok farklı bir hedefe gitmeye yol açabilir.

Çevik Gelişim Döngüsü

artilari-ve-eksileri-ile-agile-yontemler-1

Agile geliştirme döngüsündeki aşamalar burada. Bu aşamaların art arda gerçekleşmemesi gerektiğini belirtmek önemlidir; esnektir ve her zaman gelişmektedir. Bu fazların çoğu paralel olarak gerçekleşir.

  • Gereksinim analizi: Bu aşama yöneticileri, paydaşları ve kullanıcılarla iş gereksinimlerini tanımlamak için birçok toplantıyı içerir. Ekip, ürünü kimin kullanacağı ve nasıl kullanacağı gibi bilgileri toplamalıdır. Bu gereksinimler ölçülebilir, ilgili ve ayrıntılı olmalıdır.

  • Planlama: Bir fikrin uygun ve uygulanabilir olduğu düşünüldüğünde, proje ekibi bir araya gelir ve istenilen özellikleri tanımlamaya çalışır. Bu aşamanın amacı, düşünceyi daha küçük parçalara (özellikler) ayırmak ve sonra her bir özelliği önceliklendirmek ve bir iterasyona atamaktır.

  • Tasarım: Sistem ve yazılım tasarımı, önceki aşamada belirtilen gereksinimlerden hazırlanmıştır. Ekip, ürün veya çözümün neye benzeyeceğini düşünmelidir. Test ekibi ayrıca bir test stratejisi veya devam etmek için bir plan ile gelir.

  • Uygulama, kodlama veya geliştirme: Bu aşama, özelliklerin oluşturulması ve test edilmesiyle ve tekrarlama için zamanlamaların planlanmasıyla ilgilidir. Geliştirme aşaması, teslim edilen hiçbir özellik olmadığından sprint 0 ile başlar. Bu iterasyon, sözleşmelerin sonuçlandırılması, ortamların hazırlanması ve finanse edilmesi gibi görevlerle birlikte harekete geçmek için temel oluşturuyor.

  • Test: Kod geliştirildikten sonra, ürünün müşteri ihtiyaçlarını ve eşleşen kullanıcı hikayelerini gerçekten çözdüğünden emin olmak için gereksinimlere karşı test edilir. Bu aşamada, birim test, entegrasyon testi, sistem testi ve kabul testi yapılır.

  • Çıktıyı Canlıya Alma: Test ettikten sonra, ürün kullanım için müşterilere teslim edilir. Ancak, dağıtım projenin sonu değildir. Müşteriler ürünü kullanmaya başladığında, proje ekibinin ele alması gereken yeni sorunlarla karşılaşabilirler.

  • İzleme ve takip etme: Hem çıktının düzgün çalışıp çalışmadığı izlenir ve gerekirse müdahale edilir hem de kullanıcılardan geri bildirim toplanır ve yeniden gereksinim analizi ve planlamalara girdi oluşturulur.

Çevik Uygulamakta Kullanılan Metodolojiler

Agile (Çevik) bir çerçevedir ve Çevik hareketinde bir dizi özel yöntem vardır. Bunları Agile'nin farklı lezzetleri olarak düşünebilirsiniz:

  • Extreme Programming (XP): XP olarak da bilinen Extreme Programming, gelişen müşteri gereksinimlerine yanıt vermeyi ve kaliteyi arttırmayı amaçlayan bir yazılım geliştirme türüdür. XP'nin ilkeleri, geribildirimi, basitliği varsayarak ve değişimi benimsemeyi içerir.

  • Özellik odaklı geliştirme (Feature-driven development - FDD): Bu yinelemeli ve artımlı yazılım geliştirme süreci, sektördeki en iyi uygulamaları tek bir yaklaşımla birleştirir. FDD'de beş temel faaliyet vardır: genel model geliştirin, özellik listesi oluşturun, özelliğe göre plan yapın, özelliğe göre tasarlayın ve özelliğe göre oluşturun.

  • Uyarlamalı sistem geliştirme (Adaptive system development - ASD): Uyarlamalı sistem gelişimi, projelerin sürekli bir adaptasyon halinde olması gerektiği fikrini temsil etmektedir. ASD, üç tekrarlanan dizi döngüsüne sahiptir: spekülasyon yapın, işbirliği yapın ve öğrenin.

  • Dinamik Sistem Geliştirme Yöntemi (Dynamic Systems Development Method - DSDM): Bu Çevik proje dağıtım çerçevesi, yazılım ve BT dışı çözümler geliştirmek için kullanılır. Bütçe harcama, teslim tarihleri ve kullanıcı katılımı eksikliği gibi BT projelerinin yaygın problemlerini ele alır. DSDM'nin sekiz ilkesi şunlardır: iş gereksinimlerine odaklanmak, zamanında teslim etmek, işbirliği yapmak, kaliteden asla ödün vermemek, sağlam temellerle adım adım ilerlemek, yinelemeli olarak geliştirmek, sürekli ve açık bir şekilde iletişim kurmak ve kontrolü göstermek.

  • Yalın Yazılım Geliştirme (Lean Software Development - LSD): Yalın Yazılım Geliştirme Yalın üretim ve Yalın BT ilkelerini alır ve bunları yazılım geliştirmeye uygular. Yedi prensip ile karakterize edilebilir: atıkları elimine etmek, öğrenmeyi arttırmak, mümkün olduğu kadar geç karar vermek, mümkün olduğu kadar hızlı bir şekilde teslim etmek, ekibi güçlendirmek, dürüstlük oluşturmak ve bütünü görmek.

  • Kanban: Japonca “görsel işaret” veya “kart” anlamına gelen Kanban, Çevik'i uygulamak için görsel bir çerçevedir. Mevcut sisteminize küçük, sürekli değişiklikler sağlar. İlkeleri şunlardır: iş akışını görselleştirin, ilerlemedeki çalışmaları sınırlayın, akışı yönetin ve geliştirin, politikaları açık hale getirin ve sürekli iyileştirin.

  • Crystal Clear: Crystal Clear, Crystal ailesinin metodolojisinin bir parçasıdır. Altı ila sekiz geliştiriciden oluşan ekiplerle kullanılabilir ve süreçlere veya yapay dokulara değil, insanlara odaklanır. Crystal Clear aşağıdakileri gerektirir: Kullanılabilir kodun kullanıcılara sık olarak teslim edilmesi, yansıtıcı iyileştirme ve tercihen birlikte oturarak ozmotik iletişim.

  • Scrum: Scrum, Agile'yi uygulamak için en popüler yollardan biridir. Asla değişmeyen bir dizi rol, sorumluluk ve toplantıyı izleyen yinelemeli bir yazılım modelidir. Genellikle bir ila iki hafta süren sprintler ile yinelenir, ekibin yazılımı düzenli olarak teslim etmesine izin verir.

Diğer Çevik Pratikler

Çevik ile ilgili birçok başka uygulama ve çerçeve var. İçerirler:

  • Çevik Modelleme (Agile Modeling - AM): Agile modelleme, yazılım sistemlerini modellemek ve belgelemek için kullanılır ve Scrum, Extreme Programming (XP) ve Rational Unified Process (RUP) gibi diğer Çevik metodolojilerin tamamlayıcısıdır. AM, tam bir yazılım süreci değildir. Modellerin kod ile geliştirilmesine yardımcı olabilir, ancak programlama aktivitelerini içermez.

  • Rasyonel Birleştirilmiş Süreç (Rational Unified Process - RUP): IBM'in bir bölümü olan Rational Software Corporation tarafından oluşturulan RUP, yazılım geliştirme için yinelemeli, uyarlanabilir bir çerçevedir. Rational'a göre RUP, program geliştirme için yönergeler, şablonlar ve örnekler sunan çevrimiçi bir danışman gibidir. RUP'un kilit yönleri risk odaklı bir süreç, vaka odaklı geliştirme ve mimari merkezli tasarım içerir.

  • Yalın (Lean) / Çevik: Yalın geliştirme (development), atıkları ortadan kaldırmaya ve azaltmaya (herhangi bir değer eklemeyen faaliyetlere) odaklanır. Yalın geliştirme, ilkelerini Yalın üretimden alır ve bunları yazılım geliştirmeye uygular. Bu ilkeler Agile'a çok benzer, ancak Yalın bunu bir adım daha ileri götürüyor. Geliştirme aşamasında, bir sonraki özellik için işlemi tekrar etmeden önce yalnızca bir özelliği seçer, planlar, geliştirir, test eder ve canlıya alırsınız.

  • Test Odaklı Geliştirme (Test-Driven Development - TDD): Test odaklı geliştirme, tekrar eden, kısa gelişim döngülerine dayanır. İlk olarak, bir geliştirici yeni bir özellik için (başlangıçta başarısız olan) otomatik test senaryosu (test case) yazar ve bu testi geçmek için minimum kod miktarına hızlı bir şekilde bir test ekler. Ardından, yeni kodu kabul edilebilir standartlara göre yeniden düzenler (refactor eder).

  • Ölçeklendirilmiş Çevik Çerçeve (SAFe ticari marka logosu): Ölçeklendirilmiş Çevik Çerçeve, büyük işletmelerin Çevik'i benimsemeye başlamasına yardımcı olacak çok yapılandırılmış bir yöntemdir. SAFe, Yalın ve Çevik ilkelere dayanır ve büyük organizasyonlarda, mimarlık, bütünleşme, finansman ve ölçeklerdeki roller gibi zorlu sorunları ele alır. SAFe'nin üç seviyesi vardır: takım, program ve portföy.

  • Hızlı Uygulama Geliştirme (Rapid Application Development - RAD): RAD'ın yazılım geliştirme yaklaşımı, planlama görevlerinden ziyade programlamaya daha fazla önem verir. Her bileşenin paralel olarak geliştirildiği bir artımlı model izler. RAD'deki aşamalar şunlardır: iş modelleme, veri modelleme, süreç modelleme, uygulama oluşturma, test ve kurulum.

  • Ampirik Kontrol Yöntemi (Empirical Control Method) : Çevik yazılım geliştirme ile, gerçek projede gözlemlediğiniz gerçeklere dayalı kararlar aldığınız anlamına gelen Ampirik Kontrol Yöntemini kullanabilirsiniz. Proses kontrolünün ampirik modeli üç bölümden oluşur: görünürlük, muayene ve adaptasyon.

Agile'de Bütçeler Nasıl Hesaplanır?

Derinlemesine planlama olmadan, birçok proje yöneticisi bir Çevik projenin maliyetini ve bütçesini nasıl hesaplayacağından emin olamazlar.

Projenin başlamadan önce maliyeti tahmin etmek, kullandığınız proje metodolojisine bakmaksızın her zaman zor olabilir. Ancak, Çevik bir projede, projenin toplam maliyeti ile alacağı süreyi bağlayabilirsiniz.

Öncelikle, projenizde ne kadar çok sprint olacağını ve projenin ne zaman biteceğini tahmin etmek için bir burndown tablosu oluşturmalısınız ve burndown oranını kullanın. Ardından, ekibin saatlik ücretlerine göre ne kadara mal olacağını hesaplayın. Her bir kişinin oranını haftada çalışma saati sayısına göre çoğaltın, sonra bir sprint' deki hafta sayısı ile çarpın. Ekibinizin başlangıç bütçesini tahmin ettiğinizde, teknoloji, seyahat veya ekipman gibi başka maliyetler varsa onları da ekleyebilirsiniz.

Her kullanıcı hikayesini (user story) de görevlere ayırabilirsiniz. Her bir görevi tamamlamak için kaç saat süreceği konusunda bir fikriniz olduğunda, proje bütçesini tahmin edebilirsiniz.

Son olarak, geliştirme hedefleri için gereken iş gücünü tahmin etmek için planlama pokeri oynayabilirsiniz. Planlama pokeri, geliştirme hedeflerinin çabasını tahmin etmek için bir konsensüs tabanlı, oyunlaştırılmış bir tekniktir. Her takım üyesi, yüksek sesle söylemek yerine, masaya yüzleri kapalı ve üzerinde numaralar yazılı kartları kullanarak tahminlerde bulunur. Kartlar daha sonra açılır ve tahminler tüm ekiple tartışılır. Cep telefonlarında 'Scrum Time' isimli olan uygulama da bu iş için üretilmiştir.

Çevik ve Çift Programlama (Pair Programming)

Çift programlama (“eşleştirme” olarak da bilinir) Extreme Programming (XP) uygulamalarının bir parçasıdır. İki programcının bir ekran, klavye ve fareyi paylaşarak tek bir bilgisayarı paylaşarak uygulamayı geliştirir. Bu tekniğin amacı daha iyi iletişimi, sorunun netleşmesini ve çözümün anlaşılmasını teşvik etmektir. Eşleştirme, hızlı bir şekilde yüksek kaliteli ürünler sunmak için Agile projelerinde sıklıkla kullanılır, ancak her zaman gerekli midir?

Cevap programcılara, şirketinize ve hedeflerinize bağlıdır. Bazı projeler ve programcılar için eşleştirme üretkenliği artırabilir. Bununla birlikte, her proje için her zaman uygun olmayabilir. Yapılacak en iyi şey denemek ve sizin için işe yarayıp yaramadığını görmek gerekmektedir.

Agile, Yazılım Gereksinimlerini Nasıl Adresliyor

Çevik, geliştirme ekiplerinin müşterilerin en önemli gereksinimlerine olabildiğince çabuk odaklanmalarına yardımcı olur. Sürekli geribildirim ve sık yüz yüze etkileşimlerle, proje ekibi ve paydaşlar doğru gereksinimleri anlar ve önceliklendirir.

Çevik ekipler, gereksinimleri yönetmek için kullanıcı hikayelerini içeren backlog'ları kullanır. Bir iterasyon başlamadan önce, ekip bir sonraki teslimatla hangi şartları yerine getirmesi gerektiğini kabul eder. Bu işbirlikçi yaklaşım, en önemli özelliklerin önceliklendirilmesini sağlar. Ayrıca, yeni bilgiler ortaya çıktıkça, ihtiyaçlar proje boyunca sürekli olarak güncellenmektedir.

Yazılım Geliştirme Dışında Projeler İçin de Çevik Kullanabilir misiniz?

Agile geleneksel olarak yazılım geliştirme için yaratılmış olsa da, diğer birçok projede ve sanayide de kullanılabilir.

Çevik yazılım geliştirmenin Yalın üretim ve örgütsel öğrenme prensiplerinden doğduğunu unutmamak önemlidir. Bu fikirler başlangıçta yazılıma dayanmıyordu. Ayrıca, çevik toplantılar ve görsel yönetim gibi Çevik'teki birçok uygulama çok yaygındır ve herhangi bir endüstriye uygulanabilir.

Yazılım dışındaki şeyler için Agile kullanan ekiplerin çok fazla örnek çalışması yoktur ama gene de mevcuttur. Örneğin, bazı avukatlık firmaları bile kullanmaktadır. Avukatlar, beyaz tahtalar ve post-it kartları ile, sabah ayakta (stand-up) toplantıları, önceliklendirme, haftalık tekrarlamalar ve düzenli retrospektifler düzenleyerek çalışabilmektedirler.

Çevik yazılım geliştirme dışındaki projelere kesinlikle uygulanabilir, ihtiyaçlarınız için doğru yöntemi ve yaklaşımı bulmanız yeterlidir. Takımınızın nasıl tepki verdiğini görmek için tahta ve kartlar üzerinde iş biriktirmeye (backlog) girişip, stand-up toplantıları veya iterasyonlar (haftalık planlama toplantıları) ile başlayabilirsiniz.

artilari-ve-eksileri-ile-agile-yontemler-2

Agile' a Nasıl Başlanır?

Agile'a başlamak için basit bir yol vardır, günlük ayakta (stand-up) toplantılarını projenize dahil etmektir. Günlük stand-up toplantıları, halihazırda kullanmakta olduğunuz (hatta waterfall) herhangi bir proje metodolojisine dahil etmek ve herhangi bir eğitim veya bilgi aktarımı gerektirmez. Her gün yaklaşık on dakika boyunca aynı noktada buluşup herkesin bir gün önce neler yaptıklarını, bugün ne yapacaklarını ve herhangi bir engelleri olup olmadıklarını konuşmalarını isteyin.

Agile'ye tamamen geçiş yapabilmek istiyorsanız, ekibin ve organizasyonun bu değişikliği neden yapmak istediğini anlamaya başlamak isteyebilirsiniz. Çalışan ve çalışmayan şeyler neler? Neyi geliştirmek istiyorlar? Ardından, kullanılan insanların, becerilerinin ve teknolojilerin tam bir görünümünü elde etmek için Çevik bir değerlendirme gerçekleştirebilirsiniz.

Hangi yolu seçerseniz seçin, Agile'nin doğası gereği esnek olduğunu unutmayın. Agile ile başlamak için yanlış ya da doğru bir yol yoktur. Siz ve ekibiniz için uygun olanı yapın.


  Sen Ne Düşünüyorsun ?