Temel Varsayımlar

Belirli bir noktada ileriye ait öngörülerimiz o noktadaki  ufkumuzla (görebildiklerimizle )  sınırlıdır.Bu ufuktan sonrası "belirsiz bir alana" girer.Bu ufuk noktasına kadar olanları net bir şekilde görebilirsiniz daha sonrasını değil.Yaptığınız tahminler, kestirimler ne kadar uzun zaman aralığına yayılırsa(ufkunuzu ne kadar fazla aşarsa) tahminlerinizin, kestirimlerinizin doğru olma olasılığı o kadar azalır.Bu nedenle çevik geliştirmede

• Planlar kısa vadede detaylandırılır -> o noktadaki  ufkumuzda
• Uzun vadede daha genel ve esnek tutulur -> ufkumuzun dışındaki belirsiz alanda

Zamanda ilerledikçe ve elinize daha fazla bilgi geçtikçe, daha önce bilinmeyen şeyler sizin ufkunuzda girecek  artık "bilinmeye" başlayacaktır. Bu yeni ve taze bilgi ışığında , çevik geliştirmede belirli noktalarda neyi "bilip", neyi "bilmediğinizi" tekrar değerlendirip buna göre planınızı tekrar düzenlemeniz gerekir. Bu haliyle, çevik süreçlerdeki planlama bazı yöneleriyle klasik planlamadan zor bazı yönleriyle de daha kolaydır:

• Daha zordur ve daha fazla çaba ister çünkü planlama dinamik ve sürekli bir çaba gerektirir.
• Daha kolaydır çünkü  kısa sürede takımınızın  yetenekleri / becerileri  hakkında fikir sahibi olmanıza, hedeflerinizin ne kadar gerçekçi olup olmadığını görmenize ve hedeflerinize ulaşmak için daha etkin yollar keşfetmenize  yardımcı olur .Böylelikle projeyi “doğru rayına”,  doğru zamanlama ile doğru manevrayı yaparak oturtabilirsiniz.

Not: Plan nedir? : Belirli bir hedefe/amaca ulaşmak   için uygulanan strateji. [ hangi sürede nelerin yapılacağını değil ]Temelde bir plandan beklediğimiz

• işin birlikte yapılmasının eşgüdümünü sağlamak  
•  projenin yolunda gidip gitmediğini kontrol  edebilmek  ,gözlemleyebilmek için  

anahtar noktaları tespit etmemizi sağlamamasıdır. Planlarımız bu noktaları belirleyebilecek detayta olmalıdır: daha fazla detayın size ne tür bir yarar sağlıyacağını sorgulamalısınız.

İki  seviyeli bir  planlama

Çoğu iteratif   süreçte olduğu gibi çevik metodlarda da iki  seviyeli bir  planlama önerilmektedir:

• Kaba -üst seviye- bir plan: Tüm projeye ait üst seviye kaba  bir planlama -> Projeye ait fazlar, kilometre taşları, bunlara ait hedefler, kısıtlamalar  vb.
• Detaylı planlar: Projenin içinde bulunduğumuz anında,  “gelecek ufkunda” görülebilir alana ait detaylı bir planlama : Bir sonraki iterasyona ait detaylı iterasyon planları.

Uzun Vadeli Kaba (Üst Seviye)  Planlar >> Genel Proje Planlaması

Bu tür planlar hafif siklet planlar olup projenin uzun vadeli yönünü belirler. Uzun vadeli Kaba (Üst Seviye) Planlama bir şekilde nereye doğru yol alacağınızı, verdiğiniz  taahhütleri ve projenin uzun vadeli görünümünü , ara sonuçları/çıktıları belirli bir bağlama oturtacak şekilde müzakere etmenizi sağlar. Bu plan proje boyunca var olur , gelişir ve değişir.

Bu plan farlı unsurları içerebilir. Örneğin

• Ürün Vizyonu (Product Vision)
• Ürün Yol Haritası (Product Roadmap)
• Sürüm Planı (Release Plan)
• vb

Fakat bu planlamada kestirimci planlamadan farklı olarak

• Gelecekte yapılacak tüm iterasyonlara ait detaylı bir plan yoktur.
• Toplam kaç iterasyon olacağı, bunların ne kadar zaman tutacağı, her bir iterasyonda hangi sistem özelliklerin  gerçekleneceğine ait sabit bir plan yoktur.
• Paydaşların belirlediği kilometre taşları-milestones- (tarihlerle beraber), bunlara ait hedefler yer alabilir.
• Fakat bu kilometre taşlarına, hedeflerine nasıl bir yolla ulaşılacağı gösterilmez.
• Bu kilometre taşlarına doğru bir adım atıp sonra şu soruyu sorarız: "Şu an bize verilenler ve bildiklerimiz ışığındakilometre taşımızda -milestone- belirlenen hedefe ulaşmak için yapmamız gereken en akıllıca şey nedir?". Her adımda bunu tekrar ederiz.

Kısa Vadeli Detaylı Planlar >> İterasyon Planlaması

Çevik Metodlar açısından “gelecek ufkundaki” görülebilir alan bir sonraki iterasyondur. İterasyon planını Genel Proje Planı Üzerinde ilerleyen ve büyüteç vazifesi gören( detaylandıran) "sınırlı  dar bir pencere" gibi görebilirsiniz.

Bir projede herhangi bir anda genellikle "aktif" olan iki iterasyon planı vardır:

• Mevcut İterasyona Ait Plan : Mevcut iterasyondaki ilerlemenin takip edilmesi için
• Sonraki İterasyona Ait Plan : Mevcut iterasyonun ikinci yarısına doğru oluşturulmaya başlanır ve mevcut iterasyonun sonunda hazır hale gelir.

İterasyon planı ilgili iterasyonun  ötesinde (sonrasında) güncellenmez.(işi biter)
Iterasyon planı  çoğunlukla zaman sınırlı, detaylandırılmış bir plandır. XP uygulayan çoğu projede bu süre 1-2 hafta uzunluğunda olmakla birlikte diğer çevik geliştirme yönetemlerinde bu süre 1-6 hafta arasında değişebilmektedir.

Not: Zaman Sınırlı İterasyon Nedir? İterasyonun bitim tarihini sabitlemek ve değişmesine izin vermemektir.Eğer istenilenlerin(kapsam) ilgili zaman aralığında yapılamayacağı anlasılırsa,iterasyon bitim tarihinin ötelenmesi yerine, kapsam daraltılır.(önceliği az olan istekler kapsamdan çıkartılır ve diğer iterasyonlara kaydırılır).  

Zaman sınırlı iterasyonlarda zaman araliklarinin(time-box) hepsinin birbirine eşit olması gerekmemektedir. Örnegin ilk iterasyon 4 hafta, ikincisi 3 hafta olabilir.Fakat  çevik süreçlerde çoğunlukla  iterasyon sürelerinin proje boyunca-veya projenin belirli bir peryodunda- sabit tutulması tavsiye edilmektedir.Örneğin hep  iki haftalık iterasyonlar veya projenin x safhasında 2 haftalık y safhasında 4 haftalık iterasyonlar.Bazı kişiler bu tür birbirinin aynı veya  birbirine çok yakın iterasyon sürelerinin,  planlamanın ve kestirimlerin kolay bir şekilde yapılmasını sağlayan takıma ait ortak bir ritim oluşturduğu belirtmektedirler.Yine bu tür sabit iterasyon süreleri olmaksızın  geliştirme takımın  “istikrarlı” bir hıza ulaşmasının ve bunu ölçmenin  zorlaşaçağını söylemektedirler.
 
 Not: Takımın Hızı Ne Demektir? Genellikle iterasyon başına  başarılı bir şekilde gerçeklenen / teslim edilen “özellik”  (user stories, requirements, backlog items, vb) sayısı

Bir Mini Proje Olarak İterasyon

Her bir iterasyon kendi basina çesitli aktiviteleri farkli oranlarda/ağırlıklarda(projede bulunan noktaya göre)  içerir (örnegin gereksinim analizi,tasarim, programlama, test)İterasyon, iyi tanımlanmış bir çıktısı olan, mini bir proje olarak tanımlanabilir. Bu nedenle iterasyonun

• Açık ve net hedefleri
• Ölçülebilir değerlendirme kriterleri
• İterasyona tahsis edilmiş bir takımı (committed team)
• Takvimi (schedule)
• Nesnel bir değerlendirmesi

olmalıdır.
Her iterasyon  sonucunda bir “sürüm” oluşmalıdır: kararlı, bütünleştirilmiş ve test edilmiş bir sürüm.Bu sürümlerin hepsinin “dışarı”  -örneğin müşteriye-  verilmesi  gerekmemektedir.

Not:Scrum her iterasyonun sonunda “potansiyel olarak teslim edilebilir” bir sürüm oluşturulmasını ister. Burda dikkat etmeniz gereken  iterasyon sonundaki sürümün “potansiyel olarak teslim edilebilir” (dışarı-> pazara / müşteriye verilebilir) olması ile  gerçekten “teslim” edilebilir olması arasında bir farkın olup olmadığıdır. Bazen ikisi arasında çok ciddi farklılıklar olabilir.

İterasyon Esnasında Odak Noktanızı Korumak

İteratif metodolojiler degişime açiktir ama kaosa degil. Düzenli degişimlerin oldugu bir denizde bir kararlılık noktasina ihtiyaç vardir.Bir kez  ilgili itersayon ile ilgili istek alinip, yapilmaya baslandiginda, dış hiç bir paydaş işi degistirmemelidir.2  haftalik bir iterasyonun 1. Haftasinın sonunda Ürün Yönetici yazilim ekibe  “Bunu da  bu iterasyonda yapabilir misiniz?” dememelidir. Diger iterasyon beklenilmelidir: “Bunu da yapabilir misiniz? Hayir, diger iterasyonu bekliyecekler”.Eğer ilgili özelliklerin mevcut iterasyonda “mutlaka” yapılması gerekiyorsa, kapsamdaki diğer unsurlar çıkartılır. Eger istenilenlerin(kapsam) ilgili zaman araliginda yapilamayacagi anlasilirsa, takim kapsami daraltabilir.(Scrum özellikle bu unsuru vurgulamaktadır).

İterasyon Esnasında

İdealde  gereksinimlerin elde edilmesi /detaylandırılması, gerçekleştirilmesi/kodlanması ve test edilmesi  tek bir iterasyonun  içinde birlikte yapılır. Bu tür çalışma idealde en verimli olanıdır. Böyle bir çalışma yapılabilmesi için ilgili takımın farklı disiplinlerdeki kişileri bir arada barındırması gerekmektedir.[ gerek teknik kökenli kişiler, gerekse olaylara müşteri ve iş açısından bakabilen temsilcileri]

Not: Bu nedenle bazı  kişilerce “FEATURE TEAMS” takım modeli önerilmektedir. Detayları İçin Bakınız:
Craig Larman’ın “Scaling Lean & Agile Development: Thinking & Organizational Tools for Large-Scale Scrum” kitabındaki FEATURE TEAMS bölümü.


Ötelenmiş Faaliyetli İterasyonlar (Pipelining)

Gereksinim lerin Ötelendiği İterasyonlar

Bu modelde  bir grup(analist ekibi örneğin) sonraki iterasyonun gereksinimlerini elde etmekle uğraşırken, diğer grup(geliştirme takımı) mevcut iterasyon için bu grubun daha önceden elde ettiği  gereksinimlerin kodlanması ile uğraşmaktadır.İstenilen bir durum değildir. Ama büyük ve gereksinimlerin alınacağı kişilerin dışarda ve her an müsait olmadığı  durumları barındıran projelerde yapılabilecek en iyi şey bu olabilir.

Testin Ötelendiği İterasyon

Bu modelde bir grup(test takımı), geliştirme takımı N. İterasyona ait kodlamayı gerçeklerken, N-1. İterasyona ait sürümü test eder.  Bu testlerde ortaya çıkan hatalar, eğer geliştirme takımının mevcut iterasyonunda artık boş zaman kalırsa mevcut iterasyonda ele alanır,yoksa sonraki iterasyonlara bırakılır.
İstenilen bir durum değildir. Ama testlerin uzun ve karmaşık olduğu ve bu nedenle ayrı bir takım tarafında gerçeklenmesi gereken projelerde yapılabilecek en iyi şey bu olabilir.

Uyarı: Unutmayın bu tür ötemeler “kağıt üzerinde”  iyi işler gibi görünmekle beraber, ciddi yan etkilere yol açabilmektedir: takımın odağını kaybetmesi, iterasyon yönetiminin güçleşmesi,vb. Ciddi bir sebeb olmamakdıkça bu tür ötelemeli iterasyonlardan kaçınılması gerekmektedir

İlk İterasyonlarda Neler Seçilmeli?

Bazı  çevik metotlarda bir sonraki  iterasyonun kapsamı  sadece  müşteri tarafından doğrudan belirlenir.Müşteri kendi işine değer katacak en yüksek faydayı sağlıyacak özellikleri  bir sonraki iterasyonda gerçeklenmeklenmesi için seçer. Bu şekilde müşteri projeyi,o an en önemli bulduğu özellikleri  seçerek bir iterasyondan diğerine taşır . Müşterinin, yeni ve taze bilgi ışığında, ilerleyen bu süreç üzerinde kontrolü ve seçme insiyatifi vardır.Fakat sadece müşterinin seçimiyle ilerleyen bu iterasyonlar bazı sakıncalar yaratabilir. Müşteri her zaman neyin teknik olarak zor ve riskli olduğunu takdir edemeyebilir.Fakat  müşteriyi dinlemeyip sadece geliştiricilerin seçtiği teknik riskleri azaltmaya odaklı iterasyonlarla hareket etmekte bizi yanlışa sevk edebilir. Çünkü Geliştiriciler de “neyin”  yapılan işe  gerçek değer  kattığını neyin ticari önem taşıdığını takdir etmeyebilir. Bu nedenle iterasyonların kapsamını belirlerken gerek müşterinin gerekse geliştiricilerin önceliklerini  “olabildiğince” dengeleyecek bir “sepet” oluşturmakta fayda vardır: geliştiriciler müşteri açısından öncelikli olmayan ama sistem mimarisindeki ve tasarıma ait teknik risklerin bertaraf edilmesi adına önem taşıyan özelliklerin ilk iterasyonlarda yapılmasını  verilmesini müşteriden talep edebilir. Bu da müsteriyle “beraber” çalışmakla, onunla “işbirliği” yapmakla olur.

Diğer Geri Besleme Mekanizmaları

Retrospective toplantıları

Her iterasyonun sonunda ,iterasyon değerlendirmesi –review- ile birlikte ilgili paydaşlara çalışan kodun bir demosu yapılır. Yine iterasyonun sonunda takım kendi çalışma yöntemlerini iyileştirmek için “Retrospective” toplantıları yapılır.Burda takım

• Kullandıkları yönteme/metoda
• Kullandıkları mühendisilik pratiklerine
• Yaptıkları Takım çalışmasına

ait problemleri masaya yaratır, bunlarda değişikliğe gidilip gidilmemesini , sonraki iterasyonlarda “yeni şeyleri”  deneyip denememeyi  müzakere eder. Takım uzlaştığı konularda  adımlar atar.

Not: Bakınız Agile Retrospectives: Making Good Teams Great!Esther Derby,Diana Larsen

Günlük Yapılan Toplantılar

Bazı çevik metodlarda  uygulanan Günlük Ayaküstü Toplantılar (örneğin Scrum Daily Scrum Meetings) iterasyonun ve takım üyelerinin durumu hakkında
kısa ve hızlı bir bilgilendirme sağlar. Ekip üyelerinin her biri kisaca bir önceki günlük toplantidan bu yana ne yaptigini, sonraki günlük toplantiya kadar ne yapacagini, eger varsa karşılastıgı -iterasyonun hedeflerine ulasmasini engelleyen -problemleri anlatir. Bu tür günlük toplantılar temelde sık bir şekilde geri besleme almamıza olanan verirler  ve  böylece iterasyonda yanlış gideni düzeltmek adına hızlı hareket edebilmemizi sağlarlar. Bu toplantılarda temel amaç problem çözmek, veya bir karara varmak değildir.Temel amaç  iterasyondaki son durum hakkinda bilgi paylasimini saglamaktır. Bu nedenle bunlar ayak üstü yapılan kısa toplantılardır: eğer daha uzun konuşulması gereken konular ortaya çıkarsa bunlar için daha detaylı toplantılar düzenlenir.

Çevik Metodların Esas Farkı [ socio-technical ]

Çevik Metodları farklı kılan esas unsurlar arasında  ise aşağıdakiler sıralanabilir:

• Whole Team  Planning (Takım Halinde Planlama ): Çevik  Metodlar, tek başına( örneğin sadece proje yöneticisi)  değil  birlikte yapılan işbirliğine dayalı planlamayı vurgular. Örneğin ilk başlarda yapılacak sürüm planlaması veya  her iterasyon planlaması toplantıları ideal olarak bütün geliştiricilerin  ve müşterilerlerin katılımı ile yapılır. Eğer proje büyük ve alt takımlardan oluşuyorsa, en azından her takımdam bir temsilcinin bu toplantılara katılması sağlanır.
• Visible Project Plans ( Herkesçe Ulaşılabilir Görülebilir Proje Planları): Proje planları (kaba veya detay planlar) -mümkün olduğunca-  tüm takımınkolayca görebilceği şekilde sergilenir( bunun için tahtaları veye basitçe  boş duvar yüzlerini kullanabilirsiniz)
• Workers Estimate ( İşi Yapan Kestirimi Yapar ): Çevik  Metodlar, yapılacak işlere ait tahmini süre/büyüklük  kestiriminin bizzato işi yapacak kişilerce yapılmasını salık verir.
• Volunteering (Gönüllülük Esası) : Çevik Metodlardan olan XP ve Scrum yapılacak görevlerin yönetici tarafından atanması yerine,takım üyelerinin istedikleri görevlere kendilerinin talip olmalarını vurgular.
• Yönetmek  ve Kontrol etmek yerine takımı destekle ve işlerini kolaylaştır: Yöneticiler için

Not: Bu tür planlama ilk başta çoğu kişiye "radikal" "uçuk", "saçma" gözükebilir. Çoğu kişi daha önce böyle bir planlama duymadığını bile söyleyebilir. Bu aslında  değişim fazla yaşandığı deneysel süreçlerde kullanılan nispeten eski bir planlama tekniğidir: resmi adı " Rolling Wave Planning ". Yine “ehli” tarafından uygulanan herhangi bir Iteratif ve Arttırımlı Yazılım Geliştirme Metdolojisi ( Örneğin UP ) buna benzer bir planlama ile uygulayacaktır.