Waterfall Modelden Agile Spiral Modele Doğru

20 Eyl

Bir yazılımın ortaya çıkabilmesi için öncelikle müşterinin ne tür ihtiyaçlarını karşılayacağı belirlenmelidir. Daha sonra bu ihtiyaçlara uygun teknolojilerin ve yöntemlerin belirlenmesinin ardından kodlama ve test etme işlemleri gerçekleştirilerek müşteriye hazır bir ürün sunulur.

Waterfall
Waterfall Model

Yazılımın geliştirme sürecinin başından itibaren sırayla analiz, plan, tasarım, kodlama ve test süreçleri birbirini takip eden adımlar dizisidir. Bu modele waterfall(şelale) denilmektedir. Bazen bu adımlara destek(maintenance) süresi de eklenmektedir. Bir yazılımın tüm gereksinimleri müşteriden alındıktan sonra bu adımlar takip edilerek son ürün ortaya çıkmaktadır. Ancak uzun zaman alan yazılım  projelerinde zaman içerisinde teknolojilerin veya müşterilerin ihtiyaçlarının değişebileceğinden yazılımda da değişiklikler gerekebilmektedir. İki sene süren bir projeyi düşünecek olursak proje başında belirlenen istekler iki sene sonunda mevzuatlar veya iş kuralları veya teknoloji değişikliğinden dolayı bazı ihtiyaçları karşılamayabilir. İş sonunda müşterinin ihtiyaç duymadığı bir ürün ortaya çıkabilir. Diğer taraftan analiz veya planlama sırasında yapılan bir hata ancak test sırasında ortaya çıkabilir. Proje zamanlaması için yapılan tahminler tutamayabilir.

Zaman ve bütçe kısıtlamasının olduğu startup gibi bir şirket için bu tür geliştirme modeli bir süre sonra işletmeye zarar ettirmeye başlar.

Zamanla edinilen tecrübeler geliştiriceleri bu modeli biraz değiştirmeye zorlamıştır. Müşterilerin ihtiyaçlarını guruplara bölerek her ihtiyaç için analiz, plan, tasarım, kodlama ve test süreçlerini yeniden yapılması uygun görülmüştür. Bu model, spiral(sarmal) model olarak adlandırılmıştır. Spiral model agile(çevik) proje geliştirme yaklaşımı içerisinde kullanılan bir modeldir. Burada çeviklikten kasıt değişime ayak uydurabilmektir.

Spiral Model
Spiral Model

Eğer iki senelik bir proje süreniz varsa, bu model size birinci ayın sonunda müşterinin belirttiği ihtiyaçlardan birini çalışır şekilde ona sunmanızı sağlamaktadır. Müşteriye tüm proje süresi sonunda çalışan bir ürün sunmak yerine, ona her ay yeni bir özelliği devreye alınmış olan bir yazılım ürünü sunulmuş olur.

Örneğin bir hesap makinesi yapmayı tasarlıyorsanız birinci adımda dört işlemi yapabilen bir hesap makinesi yapmak ve müşteriye sunmak yeterlidir. İkinci adımda üslü ve köklü işlemler ihtiyacını karşılayan özellik eklenir. Üçüncü adımda müşteriden yeni bir talep gelir ve trigonometrik hesaplar yapabilen özellikler eklenebilir. Daha sonra gelen geri dönüşlere(feedback) göre belki matris çözebilen özellikler gerekebilir. Burada önemli olan, her adım sonunda müşterinin elinde çalışan bir hesap makinesinin olmasıdır. Eğer waterfall model ile geliştirme yapılırsa tüm özellikler ve testler bittiğinde müşteriye çalışan bir ürün teslim edilir. Belki de müşterinin hiç ihtiyaç duymayacağı matris işlemler özelliğini de eklemiş olabilirsiniz. Şunu unutmamalıyız ki; gereksiz işlere harcanan zaman, işi yapan tarafa gider olarak yazılır

Agile Manifesto

Agile(çevik) yazılım geliştirme yaklaşımı bir işi küçük parçalara bölerek yapmayı ilke edinen bir disiplindir. Bir ürün veya yazılım aracı veya bir kodlama yöntemi değildir.

Agile (çevik) yazılım geliştirme konusunda, yazılım sektöründe tecrübeli bir ekip tarafından bir manifesto yayınlanmıştır. Manifesto içeriğine ve ilgili kişilere  http://www.agilemanifesto.org/ adresinden ulaşabilirsiniz.

Agile manifestonun dört temel ilkesi vardır.

English:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

Türkçe:

  1. Süreç ve araçlardan ziyade bireyler ve etkileşimler
  2. Kapsamlı dökümantasyondan ziyade çalışan yazılım
  3. Sözleşme pazarlığından ziyade müşteri ile işbirliği 
  4. Plana bağlı kalmaktan ziyade değişime yanıt vermek 

Bu ilkeler ne anlama geliyor?

Manifesto ilkelerinde, yazılım geliştirme sürecinin önünü açan öncelikler belirlenmiştir. Tüm cümlelerde ortak olarak kullanılan “ziyade” kelimesi işte bu öncelikleri vurgulamaktadır.

1. Süreç ve araçlardan ziyade bireyler ve etkileşimler: Yazılımlar bilgisayarlar tarafından çalıştırılan ürünler olsa da yazılımı talep eden müşteriler ve onu geliştiren programcılar insanlardır. Müşteriler ve geliştirici ekip arasında güçlü bir iletişim olmalıdır. Ürünler ve araçlar değişebilir, eskiyebilir ve gözden çıkarılabilir. Fakat birbiriyle uyumlu iyi bir ekibiniz varsa onu gözden çıkaramazsınız. Bu nedenle bireylere değer vermek işletilen süreç ve kullanılan araçlardan daha önemlidir.

2. Kapsamlı dökümantasyondan ziyade çalışan yazılım: Projelerde müşteri ile el sıkışmanın şartı iş sonunda çalışan kaliteli bir yazılımın olmasıdır. Müşteriler kapsamlı dökümanlara para ödemek istemez ama tercihen isterler. Müşteriyi boğmayan ancak ona yeteri kadar bilgi veren bir dökümantasyonunuz olmalıdır. Bu nedenle önceliğimiz çok kapsamlı bir dökümantasyon oluşturmak yerine iyi çalışan bir yazılım olmalıdır.

3. Sözleşme pazarlığından ziyade müşteri ile işbirliği: Müşteri tarafından sunulan şartnameler ve yapılan sözleşmeler her iki tarafa güvenlik duygusu verir. Bir sözleşmeye imza atılır ve belirli bir zamanda yapılacak işler planlanmış olur. Agile süreçlerde her zaman müşteri ile işbirliği ön plandadır. Kararlar beraber alınır, sürekli görüş alışverişi yapılır, teslimatlar sonrasında geri bildirimler alınarak değerlendirmeler yapılır. Yani iş sözleşmesini ve talepleri alıp iş bitiminde görüşmek diye bir şey olmaz.

4. Plana bağlı kalmaktan ziyade değişime yanıt vermek: Agile yani çeviklik bir plana bağlı kalmadan değişime cevap vermek demektir. Zamanla gereksinimler, mevzuatlar iş kuralları değişebileceğinden uyguladığınız çözüm yöntemi de bu değişimlere ayak uydurabilmelidir.

Agile süreçlerde Scrum, Kanban ve Lean gibi proje yönetim yaklaşımları yanında Extreme Programming(XP) gibi yazılım geliştirme yaklaşımları kullanılmaktadır. Extreme Programing yazılım geliştirme yöntemleri, uzun yıllar tecrübe edilmiş ve kendini kanıtlamış yöntemler olarak bilinir. Bunlar arasında Test Driven Development gibi önce test kodunun yazılıp ardından çalışan kodun üretildiği bir yaklaşım vardır. Pair Programming yani eşli programlama diye bilinen iki programcının aynı kodu geliştirdiği yaklaşımlar vardır. Geliştiricilerin birbirlerinin kodunu incelemesi ve yorumlaması(core review) da yine bir diğer yaklaşımdır.

Bütün bu yöntemler yazılımın türüne bağlı kalmadan uygulanabilecek yöntemlerdir. Yani web uygulaması, mobil uygulamalar, oyunlar veya masaüstü uygulamaları gibi her türlü projede çevik yöntemler uygulanabilmektedir.

Neden Agile?

Bu sorunun birinci nedeni agile kavramının değişime cevap verebilme yeteneğidir. Agile geliştirmenin bir diğer nedeni ise çabuk sonuç alma isteğidir. Taleplerin adım adım karşılanıp çalışan ürünlerin müşteriye sürekli teslim edilmesi neticesinde size olumlu veya olumsuz geri bildirimler akmaya başlar. Müşteri ile işbirliği içinde olduğunuzdan doğru şeyi yapıp yapmadığınızı hemen anlayabilirsiniz. Bu sayede harcadığınıza karşılık kazandığınızı görebilirsiniz yani yatırım getirisi (Return on investment) hakkında bilgi sahibi olabilirsiniz. Agile süreçlerde büyük bir yazılımın küçük parçaları ile çalışıldığı için erken yapılan hatalar büyük bir felakete neden olmaz. Diğer bir deyişle hatanın erkenden fark edilmesi sağlanmış olur. Ekiplerin düzgün bir yapıda oluşturulması ile kaynak planlaması da daha mantıklı olacaktır. Örneğin waterfall yöntemi ile yapılan bir yıllık bir projede analiz için gerekli çalışanların işi üç ayda bittikten sonra gereksiz yere projede tutmak istemeyebilirsiniz. Ancak ilerde analiz ile ilgili bir sorun çıkarsa diye tutmak zorunda kalabilirsiniz. Spiral yöntemde ise her döngüde süreç adımları yeniden ele alındığı için bu duruma uygun bir takım oluşturulabilir.

 

ThoughtWorks ve Martin Fowler İstanbul’daydı

14 Eyl

ThoughtWorks-Martin-Fowler-550Yazılım sektörünün önde gelen isimlerinden biri olan yazılım Martin Fowler, hepsiburada.com şirketinin sponsorluğunda düzenlenen “Contunious Delivery and Design”  isimli etkinlik için 10-11 Eylül tarihlerinde İstanbul’daydı.

Martin Fowler’ın üzerinde çalıştığı kurumsal mimari ve prensipler birçok yazılımcı tarafından kabul görmüş ve standart olarak uygulanır hale gelmiştir. Bu da Fowler’ı sektörde öne çıkarmıştır. Kendisi şu anda ThoughtWorks adlı bir yazılım danışmanlık şirketinde “Chief Scientist” pozisyonunda çalışmaktadır. Yazdığı kitaplar ve verdiği seminerlerde çok önemli konulara değinir. Bu yüzden İstanbul’daki etkinliğe katılmak istedim. Etkinliğe yaptığım ilk başvuruda yer olmadığı şeklinde olumsuz cevap gelmişti ancak 4 gün kala yer açıldı diye bir davetiye aldım ve katıldım.

Etkinlikte ThoughtWorks şirketinin İstanbul ofisinin açılmış olduğu duyuruldu. Aynı zamanda hepsiburada.com şirketi, çevik(Agile) süreçlerin ve sektördeki yenilikçi birçok deneyimin uygulanması için ThoughtWorks ile beraber çalıştığını duyurdu.

Fowler’ın sunumunda genel olarak çevik süreçlerin işleyişi üzerinde duruldu. Günümüzde artık yazılım ürünlerinin girdileri arasında insan iş gücü maliyetinin sadece yazılımı ilk oluştururken değil daha sonraki aşamalarda dönüşüm ve bakımların yapılmasının da dahil olduğu ortaya çıkmaktadır. Dönüşümün rahatça yapılabilmesi ve kaynakların israfını önlemek için çevik prensiplerin uygulanmasının gerekliliği vurgulanmıştır.

Uygulanan prensipler ve yenilikçi bazı teknik çözümlere başlıklar halinde değinilmiştir. Bunlar:

  • Continuous delivery
  • Continuous deployment
  • CAP Teorem
  • NoSQL
  • Microservices

Etkinlikte söz alan diğer konuşmacılar:

  • David Elliman
  • Emre Ekmekçi
  • Cengiz Han
  • İsa Göksu
  • Ben Kappler

Etkinlikte ayak üstü sohbetlerde çeşitli şirketlerin çalışanlarıyla sohbet imkanım oldu. Merak ettiğim bir numaralı konu olan çevik süreçlerin uygulanıp uygulanmadığıydı ve  sordum. Genel olarak aldığım cevap “Türkiş Agile” yapıyoruz  oldu. Yani işin başında prensipleri uygulamaya karar verip işler yetişmediğinde hadi bakalım eski düzene dön şeklinde devam eden bir sürecin uygulandığını öğrendim. Aslında farkındalığın olması bile iyi bir seviye. Bir gün mutlaka taşlar yerine oturacaktır. Martin Fowler’ın da dediği gibi yazılımda tecrübe çalışırken öğrenme şeklinde olur.

Dünyaca ünlü yazılım şirketlerin ülkemize ilgi göstermeye başlamasını şahsen çok önemsiyorum. Yıllar önce kurulan şirketlerin coğrafyamızda bu günlerde yüzünü göstermeye başlaması sanırım bir şeylerin değiştiğinin göstergesidir. Bugün Martin Fowler geldi. Kim bilir yarın Robert Cecil Martin, başka bir gün Kent Beck, Eric Evens, Erich Gamma gelir.

Scrum Kavramları

13 Nis

Scrum yaklaşımı üç ana kavram üzerinde inceleyebiliriz. Bunlar: product backlog, sprint backlog ve burn-down chart şeklindedir. Bu elemanlar Scrum yaklaşımı ile geliştirme yaparken takımlara yardımcı olan, yön veren ve projedeki şeffaflığı sağlayan elemanlardır.

Product Backlog (İstekler listesi)

Bir projede takımın tamamlaması gereken işler listesidir. Bu liste müşterinin ürününde ihtiyaç duyduğu ve yapılmasını istediği işlerin listesidir. Scrum yaklaşımının kilit bileşeni olan kullanıcı hikayeleri (user story) bu listenin temelini oluşturmaktadır.

Product Backlog listesi Product Owner tarafından yönetilir. Product Owner kullanıcı hikayelerini (user story) listeye eklemek ve çıkarmakla sorumludur. İstekler listesi müşteri ve Product Owner tarafından öncelik sırasına göre sabit bir şekilde oluşturulur. Bu sabit öncelik sırası Scrum kavramını kilit noktasıdır. Çünkü müşteri için en değerli hikayeler listede en üst sırada yer alacaktır. Kullanıcı hikayeleri eklendikçe listedeki diğer hikayelerle karşılaştırılıp müşteriye göre uygun öncelikli bir yere koyulacaktır. Sprint süresince product backlog listesine kullanıcı hikayeleri eklenmeye devam edebilir. Ancak Sprint tamamlanana kadar eklenen istekler Yürütülmekte olan Sprint turuna sokulmaz ve takıma sunulmaz.

User Stories (Kullanıcı hikayeleri)

Daha önce de belirtildiği gibi Product Backlog listesi öncelik sırsına konulmuş kullanıcı hikayeleri listesidir. Bir kullanıcı hikayesi müşteriye göre değer ifade edecek şekilde kartlara yazılır. Kullanıcı hikayesi geliştiriciye iş önceliği ve önem değerini anlatmak için yazılır. Kullanıcı hikayeleri bir pano üzerine dikey sırada olacak şekilde asılır. Kullanıcı hikayeleri INVEST diye kısa bir isimle adlandırılan kurallar dizisini içerirler. Aşağıdaki listenin baş harflerini birleştirdiğimizde INVEST kelimesi oluşur.

  • Indipendent(Bağımsızlık): Kullanıcı hikayesi kendi başına bir içeriğe sahip olmalıdır. Diğer kullanıcı hikayelerine bağlı olmamalıdır.
  • Negotiable(Tartışılabilir): Kullanıcı hikayeleri, bir sprint döngüsüne girene kadar her an değiştirilebilir.
  • Valuable(Değer): bir kullanıcı hikayesi son kullanıcı için bir değer ifade etmelidir.
  • Estimable(Tahmin yürütülebilir): Bir kullanıcı hikayesinin süresi tahmin edilebilmelidir.
  • Sized appropriately(Makul boyut): Kullanıcı hikayeleri plan, görev ve öncelik bakımından derecelendirilmesi ele alınabilmesi için çokkompleks yapıda olmamalıdır.
  • Testable(Test edilebilirlik): Kullanıcı hikayeleri test edilebilirliği mümkün kılmalıdır.

Sprint Backlog(Sprint Listesi)

Bir Sprint turunda takımın yapacak olduğu işlerin listesidir. Product Backlog listesinin bir alt kümesi olarak düşünülebilir. Product Backlog içerisinde ürüne ait tüm kullanıcı hikayeleri yer alırken Sprint Backlog içerisinde Sprint içerisine alınmış hikayeler ve görevler yer alır. Bir Sprint döngüsü için seçilen bir kullanıcı hikayesi görevlere bölünerek takımda bulunan üyelere dağıtılır.

Görevler ise kullanıcı hikayelerini oluşturan iş birimleri olarak düşünülebilir. Her bir iş birimi bir takım üyesine atanır. Örneğin bir kullanıcı giriş ekranının tasarlanması veya bir ürün kataloğunun hazırlanması birer görev olarak düşünülüp takım üyelerine dağıtılabilir. Bu görevler kartlar üzerine yazılarak bir görev panosuna iliştirilir. Ancak günümüzde gelişmiş yazılımlarla görev panoları yerine bilgisayar ortamında da kayıtlar tutulabilmektedir.

Script Backlog
Script Backlog

Sprint listesi aynı zamanda iş bitim grafiği(burn-down chart) için de gerekli bilgileri hazırlamaktadır. Her Sprint turunda Sprint panosu boşaltılır. Kalan işler olursa product backlog listesine geri iade edilir.

Born-down chart (İş sonu grafiği)

Sprint turu sırasında takım üyeleri görevlerini yerine getirildikçe kalan iş ve yapılan iş arasındaki korelasyonu belirten bir grafik ortaya çıkmaktadır. Bu grafik takım üyelerine veya yöneticilerine fikir vermektedir. Aynı zamanda takımın iş için istediği sürelerin yeterli olup olmadığı ve işin zamanında tamamlanıp tamamlanamadığı konusunda da fikir veren bir grafiktir. Grafiğin İngilizce adı olan burn-down, sözlük anlamı olarak yanıp bitmek şeklinde ifade edilmektedir. Bunu bir mumun yanarken zamana göre boyunu izlediğimizde bu şekilde bir grafik ortaya çıkar. Scrum yaklaşımında da yapılacak olan işler bittikçe zamana göre azalacak ve belirlenen süre sonunda sıfırlanacaktır.

Burn-down chart
Burn-down chart

Scrum Nedir?

10 Nis

Çevik yazılım geliştirme ilkelerinin uygulandığı iteratif bir geliştirme yaklaşımıdır. Scrum yaklaşımı “Sprint” diye adlandırılan zaman dilimlerinden oluşmaktadır. İki veya dört haftalık bu zaman dilimleri sonunda teslimata hazır çalışan programların ortaya koyulması amaçlanmaktadır.

Çalışmalar ürün yöneticisi(product owner) tarafından yapılacaklar işler listesindeki(product backlog) önem sırasına göre dizilir. Sprint’ler oluşmadan önce yapılacaklar listesinden bir iş seçilir ve takım ile iş teslim taahhüdü yapılır.

Her şeyin sorunsuz olması ve teslimin zamanında yapılabilmesi için ScrumMaster diye adlandırılan bir lider, takımın önündeki engelleri kaldırmakla sorumludur. Her gün ayakta yapılan yarım saatlik toplantılarda takım ile teslime engel olabilecek sorunlar ve son durumlar hakkında konuşmalar yapılır.

Aşağıdaki resimde Scrum sürecini anlatan grafiksel bir temsil bulunmaktadır.

Scrum Süreci
Scrum Süreci

Her bir Sprint süresi 2-4 haftadır. Takımlar proje yöneticisi(ScrumMaster) ile her Sprint başlangıcında toplantı yaparak geliştirilecek özellikleri belirlenir. Bu süreçteki özellikler daha önceden oluşturulmuş ve sürekli güncellenen yapılacak işler listesinden(Product Backlog) önem sırasına göre seçilir. Seçilen özellikler Sprint Backlog deinlen yeni bir listeye yazılır. Artık Sprint döngüsü başlamıştır ve sadece ellerindeki Sprint listesiyle ilgilenirler. Bir sonraki Sprint döngüsü başlayana kadar Product Backlog listesine bakmazlar.

Her gün ayakta yapılan ve en fazla 15 dakika süren toplantılar(Dailit Stand-Up) ile sorunlar ve ilerleme durumları ele alınır. Sprintler sonunda teslimata hazır çalışan bir program ortaya çıkar.

Scrum yönteminin sağladığı en büyük faydalardan biri şeffaf ve raporlanabilir bir geliştirme sürecine sahip olabilmektir. Raporlar sayesinde geçen zaman ve kalan zaman grafiklerine bakılarak durum gözlemi yapılabilmektedir.

Kaynak: ProAgile .Net Development with Scrum

Çevik Süreç Prensipleri – Agile Principles

9 Ağu

Bu yazıda çevik süreçlerde benimsenen 12 prensibi ingilizce ve türkçe anlamlarıyla açıklamaya çalıştık. Çevik süreçlerde proje geliştirenlerin bu ilkelere uyması gerekmektedir. Şunu da belirtmekte fayda var ki, çevik süreçler bir yazılım geliştirme metodu değildir. Yazılım geliştirme disiplinidir. Belli kurallar dahilinde ilerlemeyi amaçlayan bir disiplindir. Aşağıdaki ilkelerle de bu disiplini anlamaya çalışalım.

EN: “Our highest priority is to satisfy the customer through early and continuousdelivery of valuable software.

TR: “En önemli önceliğimiz, çalışır haldeki programları kısa sürelerde oluşturup teslim ederek müşteriyi tatmin etmektir.

Müşterinin tatmin olması demek, müşterinin yaptırdığı projenin ilerleyişini görerek eksikliklerinin giderilmesi ve aklındaki soru işaretlerinin ortadan kalkmasıyla olu. Bu sadece yazılım işinde değil diğer sektörlerde de böyledir. Örneğin inşaat işi yaptırıyorsa sık sık gidip inşaat alanını gezer. Müşteri işin istediği gibi ilerlediğini gördüğünde tatmin olur. İş bitiminde de müşteri isteklerini karşılayan bir proje teslim edilmiş olur.

 EN: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

TR: “Yazılımdaki değişiklikler hoş karşılanmalıdır. Bu değişiklikler yazılım süresini uzatsa bile hoş karşılanmalıdır. Çünkü çevik süreçler değişiklikleri müşterinin rekabet avantajını korumak için kullanılır.

EN: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.”

TR: “Birkaç hafta ile birkaç ay gibi kısa zaman dilimlerine çalışan yazılımları oluştur.

Müşteriye plan ya da belgeleri teslim etmek değil çalışan programları sunmak gerekir. Teslimatlar arasındaki değişim, gelişimin göstergesidir.

EN: “Business people and developers work together daily throughout the project.”

TR: “Müşteri ve programcılar proje boyunca beraber çalışır.

Projenin çevik olması; müşteri, programcılar ve hissedarların beraber etkileşim içerisinde olmasını gerektirir. Müşteri veya programcı tarafındaki gereksinimlerin anında giderilmesi sağlanır.

EN: “Build projecsts around motivated individuals, give them the environment and support they need and trust them to get the job done.”

TR: “Motivasyonu yüksek bireylerle proje oluştur. Onlara ihtiyaç duydukları ortamları sağlayarak işi yapabilecekleri konusunda onlara güven.”

Bireyler en önemli başarı faktörüdür. Her birey takımın bir parçasıdır. Bireyler, kendilerine duyulan güvenle motive olurlar. Bu şekilde kendilerini önemser ve işe verirler. Yardımlaşma ve dayanışmayla, bilgi bakımından kısa sürede aynı standartlara gelirler.

EN: “The most efficient and effective method of conveying information with and within a development team is face-to-face conversation.”

TR: “Bilgi alışverişinde en etkili yöntem yüz yüze görüşmektir.

Çevik süreçlerde insanlar birbirleriyle konuşurlar. Ekip, konuşarak sorunların çözümüne daha kolay oluşur.

EN: “Working software is the primary measure of progress.”

TR: “Çalışan yazılım, sürecin işlediğinin birincil göstergesidir.

Çevik projelerde sürecin ölçütü, o anda müşterinin ihtiyacını karşılayan bir yazılımın ortaya koyulmasıyla belirlenir. Sunulan ilerleme raporları veya dökümantasyonlar ile ölçüm yapılmaz. Dökümanlar yalan söyleyebilir fakat çalışan uygulama gerçekleri söyler. Bu da çevik süreçlerin müşteri lehine olduğunu gösterir.

EN: “Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.”

TR: “Çevik süreçler sürdürülebilir gelişimi destekler. Müşteriler, yazılımcılar ve kullanıcılar bir arada çalışabilmelidirler.

Süreç istikrarlı bir şekilde ve rutin bir tempoda ilerlemelidir. Motivasyonun bozulmaması açısından aşırı iş yükü ve fazla mesai hoş karşılanmaz. Görevler, ekibe adil bir şekilde dağıtılır.

EN: “Continuous attention to technical excellence and good design enhances agility.”

TR: “Teknik mükemmelliğe sürekli özen gösterilmesi ve iyi tasarım, çevikliği güçlendirir.

Hızlı ilerlemek için, yazılımın temiz ve sağlam tutulmasıyla olur. Bu yüzden tüm ekip en kaliteli kodu üretmek için kararlıdır. Hataları gidermeyi ve kod iyileştirmelerini refactoring sırasında gerçekleştirebilirler.

EN: “Simplicity – the art of maximizing the amount of work not done – is essential.”

TR: “Baitlik esastır.

Çevik takım üyeleri, hedeflerine uygun en basit çözümü uygularlar. Karmaşık ve gereksiz kod yazmaktan kaçınırlar. Bugün yarın şu da lazım olur diye iş yapmazlar. Günün ihtiyaçlarına uygun en basit çözümü sunarlar.

EN: “The best architectures, requirements and designs emerge from self-organizing teams.”

TR: “En iyi mimariler, gereksinimler ve tasarımlar kendi kendine organize olan takımlardan çıkar.

 Çevik ekipler kendi kendine organize olabilirler. Sorumluluklar ekibe eşit şekilde paylaştırılır.  Bu sorumlulukları yerine getirmek için en iyi yol belirlenir.

EN: “At regular intervals, the team reflects on how to become more effective, then

tunes and adjusts its behavior accordingly.”

TR: “Takım, nasıl daha etkili olabileceği konusunda kendini belirli aralıklarla sorgular ve buna göre davranışlarını belirler.

 Çevik bir ekip sürekli olarak, kuralları, ilişkileri, sözleşmeleri ve organizasyon yapısını ayarlar.