İş Analisti rolü hakkındaki en temel yanılgı

İş analizinin anayasa kitabı olan BABOK’ta analist tanımlanırken REQUIREMENT sözcüğünden bahsedilmez. SOLUTION geçer. O zaman birçok analistin kendini tarif ederken veya işverenler tarafından iş analisti ararken düştüğü en temel yanlışlardan veya eksikliklerden biri de “Analist ihtiyaç analizi yapar” tanımıdır. BABOK der ki “Analyst recommends solutions”. Solution nedir diye devam eder tarifine: “Solution enables organization’s needs, solves a problem and takes an advantage of oppurtinities”. Buraya kadar Requirement tanımlamalarda yoktur. Sonrasında şunu der ama. “Requirements help to solve problem and achieve an objective”. Demek ki ihtiyaçlar çözüm üretmek için yardımcı elemanlardır. Yardımcı elemanlar bir işin en temel tarifinde yer teşkil etmemeli.

Buradan çıkacak sonuç şudur. Analist ihtiyaçları analiz eder ama bundan çok daha öncesinde organizasyonun mevcut durumunu anlayıp (ki bu ifade de BABOK’ta vardır) bu duruma uygun çözümleri tavsiye eder. Sonrasında oluşan fikir birliği ile (ki bu fikir birliği analistin önerdiği çözümlerin dışında bir öneri de olabilir) oluşan çözüm önerisine yardımcı olabilecek ihtiyaçlar belirlenir.

Yazıyı uzatmayıp her analistin bu konuyu sıkılmadan tekrar düşünebilmesini amaçladım. Çok önemli bir konu. Çünkü yanlış başlanan her iş yanlış biter. 

Agile Sistemlerde Analist ve Product Owner?

Kurumların Bilişim politikalarına göre istihdam ettikleri 2 tür analist vardır.

Bir grup ağırlıklı olarak yazılımı iyi bilen yazılım ekibiyle teknik konuşabilen ve gerektiğinde yazılım ve diğer mimari konularda yorum yapabilen Sistem Analisti vasıflı kişileri tercih ederler.

Diğer grup işkolunun tüm ihtiyaçlarını sonuna kadar detaylandırabilecek ve bunu yazılıma olduğu gibi aktaracak, mimari ve yazılım konularında suya sabuna dokunması arzu edilmeyen İş Analistlerinden yana tercihlerini kullanırlar.

Bu iki pozisyon da Bilişim grubun bünyesinde genellikle istihdam edilir. Ve elbetteki domain bilgisi (iş bilgisi) yeterli kişilerdir. Ve Analistler işi isteyen iş kolu (SME) adına karar veremezler. her zaman ihtiyacı iş kollarından alır ve analiz ederler.  

Agile yöntemlerdeki Product Owner rolü ise İş analisti gibi davranan ve ihtiyaçları detaylı bir şekilde yazılıma aktaran fakat işi isteyen iş biriminden birine daha yakın bir pozisyondur. Bu pozisyon hem işbirimi olarak ihtiyaçlara karar veren hem de bu ihtiyaçları detaylandıran kişidir.

Şimdi Türkiye özelinde bakacak olursak: Product Owner İş Analisti pozisyonuna daha yakındır. Fakat İş analisti iş kolu (SME)’ndan biri olmadığı ve ihtiyaçlara ilişkin karar veremediği için Agile metodolojinin etkinliği açısından yeterince kapsamlı yetkilere sahip değildir. Agile sistemlerde iş kolu (SME) ile yazılım arasındaki “Customer Collobration” döngüsünde iş analisti ve iş kolu (SME)nun farklı rollerde olması karar hızını azaltmaktadır.

Sonuç:  Agile süreçlerde Product Owner olarak tanımlı bir rol yoksa, İş analistine SME tarafından daha fazla karar alma yetkisi verilmelidir. Bir iş analistinin bu yetkiyi alabilmesi iki şeye bağlıdır. Birincisi, Analist karar alma konusunda yeterliliğe sahip olmalıdır. İkincisi ise İş analisti domain bilgisini mümkün olduğunca ileri bir seviyeye taşımalı ve SME yönetimi tarafından iş kolu kararlarını almaya yetkili hale getirilmelidir. 

Scrum vs Kanban

Agile manifestonun sitesini açtığımızda karşımıza çıkan dört manifestodan ilki şudur.

“interactions and individuals over processes and tools”

(agilemanifesto.org)

Agile manifestonun 17 fikir babası, yapılandırılmış süreçleri ve buna bağlı çeşitli araçlardansa interaktif  iletişimi tercih ettiğini belirtir. İşin sonuca ulaşması için, düzenli toplantılar, süreç toollarında günlerce uğraşılarak çizilmiş labirent gibi süreçler, katı hiyerarşiler, …. yerine takımın iletişimi ve etkileşime dayalı hızlı aksiyon alması agile manifestonun ilk kuralıdır.  

Hal böyleyken katı agile metotlarından söz etmek agile ruhuna çok da uygun düşmeyebilir. Çünkü her metot kendi içinde kurallar, süreçler ve yapılandırılmış araçlar içerir haliyle. Ne var ki agile proje geliştiriyorum deyip manifesto kurallarını ezberleyip tekrarlayarak proje geliştirilmesi de mümkün olmayacağı için bazı yöntemler esas alınabilir.  İnsan doğası işte kuralsız yaşayamaz…

Neyse. gelelim  Scrum ve Kanban ilişkisine. Burada Scrum ve Kanban’ın (özellikle de scrum’un)  tekniklerini anlatmayacağız. Esas olarak, temel prensiplerini ve temel farklarını ortaya koymaya çalışacağız.

İkisi arasında çok temel 2 fark vardır.

Birinci Fark, scrum temel olarak sprint bazlı olarak ilerler. Bu yüzden kesikli teslimat söz konusudur. Kanban ise süreklidir. Proje başlangıcından sonuna kadar sürer.

İkinci Fark, Scrumda yapılacak işlerin boyutu her sprint öncesinde development takımı tarafından belirlenir. Kanbanda ise WIP limitine göre her adımdaki limite göre sürekli doldur boşalt yapılır. Hangi işin yapılacağı development tarafından belirlenmez.

WIP (Work In Progress) Limiti: Proje başlamadan önce iş akışının en yavaş noktasına göre belirlenir. Bu yöntem ilk Toyota’da ara stokları düşürmek için kullanılmıştır. Örneğin; Yazılım üretim hattında 3 temel akış bölgesi olsun. Önyüz yazılımı, servis yazılımı ve test.  Bu akışta servis yazılımı yapacak kişi çok yoğun ve servis işleri çoksa bu kişinin hızına göre servis yazılımı akış noktasına göre bu kişiye bir seferde en fazla kaç task verilecekse WIP bu olur.

Bu iki farkı aşağıdaki şekil üzerinde izah edecek olursak ;

A, B, C gibi harfler her bir taskı ifade eder. Product Backlog SME ile üzerinde mutabakata varılan “Task-Story-Epic” listesidir.

SCRUM KANBAN AKIŞ

Kanban’da Proje başladıktan sonra Product Baclog üzerinden iş akmaya başlar. Aşağıdaki kanban boardda  herhangi bir anda todo bölümünde ilk 3 LŞT taskları olsun. Bu adımda In Progress adımına gidecek 3 task bellidir. Bu tasklardan örnğin l taskı çekildikten sonra Product Backlog’tan sorumlu kişi kendi belirlediği Q taskını Todo adımına ekler. (WIP Limit 3 olduğu için o kolonu maksimum 3 yapabilir)  Hangi taskı ekleyeceğini SME ile yaptığı önceliklendirmeye göre belirler. Aynı şekilde Todo adımındaki 3 tasktan hangisini In Progres adımına çekeceğine takım üyeleri karar verir. Bu süreç tüm product backlog bitene kadar tekrar eder.

KANBAN BOARD

Dikkat edilirse Kanban Board üzerinden hiçbir adımda WIP’ten fazla task bulunmuyor ve tasklar bitene kadar board kolonları boş kalmıyor. Boş kaldığı durumda takımda ilgili adımdan iş alacak kişiler kilitlenir ve boş kalabilir.

Scrum akışına bakarsak,  her sprint öncesinde SME önceliğine göre takım kendi yapabileceği kadar task üzerinde uzlaşır. Sprint 3 için bakacak olursak takım O,S,Z,Ş,Q,L  tasklarını bitireceğini taahhüt etmiştir. Bu durumda takım sprint sonuna kadar bu 6 taskı teslim etmek zorundadır. Sprint başında bu 6 task aşağıdaki gibi boarda eklenir. Bu board üzerinde sadece bu 6 task hareket eder.

Sprint sonunda bu 6 task bitirilir. Sonraki Sprinte geçildiğinde tüm backlog taskları bitene kadar aynı şekilde sprintler devam eder.

SCRUM BOARD

Agilist Değil Agile Analist Olmak

İlk gerçek bilgisayar ENIAC 1946 yılında kurumsal olarak ve çok kısıtlı olarak kullanılmaya başlandı. *

Yazılım sektörünün yaygınlaşmasının geçmişi 30 yıldan fazla değil. (1986: windows 1.0) Aslında çok yeni ve bir o kadar da kapsamlı bir alan.

İlk uçak ne zaman uçtu. 1903 yılında. Tam 110 senedir. Ama halen gökyüzünde uçan yüzlerce kişisel uçak göremiyoruz. 

Ya da otomobile bakalım 1769 yılında ilk hareket eden araç yapıldığından bu yana 250 yıl oldu neredeyse ve halen otomobiller bozuluyor, benzin yakıyor, insana ihtiyacı var, gibi gibi. 

Demek ki her yeniliğin bir gelişme ve ilerleme evresi vardır. Bu evreler bazen önceki evreyi tamamen değiştirirken bazen de  doğrular ya da kısmen değiştirir. 

Dünyanın gündeminde kısa süredir yaşam süren bir yenilik Bilişim ve Yazılım teknolojileridir. Kısa sürede Yazılım dünyasında bir çok yeni yazılımsal yeniliklere imza atıldı. Bu yenilikler o kadar hızlı oldu ki, yazılım piyasası, gerçek dünyanın taleplerine cevap verme konusunda çok iddaalı olunca bir çok yazılım projesi (ki şimdi hatırladığım %75'tir) ya başlamadan ya da başladıktan kısa bir süre sonra fail oldu. 

Fail olan projelerle birlikte yazılım dünyasında proje metodolojileri daha sık sorgulanır hale geldi. Agile süreçler de bu sorgulamaların bir sonucu olarak ortaya çıktı. Fakat bu metot diğer metodolojileri tamamen kullanışsız hale getirmedi. Agile var diye Waterfall öldü denilemez. Fakat Waterfall metodolojide kapatılamayan bazı açıklar Agile ile kapatıldı denilebilir.

Diğer bir deyişle tamamen Agile metotla proje geliştirmek verimliliği arttırmak yerine azaltabilir ya da maksimum verime ulaşmayı engeller. Bu durumda yönetimler, Agile veya Waterfall süreçlerle ilerleme kararını vermeden önce iki sürecin de farklı proje tiplerinde kullanabileceklerini gözönünde bulunarak SDLC süreçlerini revize etmeleri verimliliğin artmasında etkili olacaktır. 

Agile metodoloji, değişkenlik arzedebilecek ve projenin ilerleyen aşamalarının kendini bir öncekine göre veya piyasadaki koşullara göre yeniden adapte edeceği bir yöntemdir. Projelerin böyle bir niteliği yoksa ve duruma veya şartlara göre değişmeyecekse Agile yerine tüm ihtiyaçları tek seferde analiz etmek ve tek seferde yazılım ile entegre edecek Waterfall metotlar kullanılmalıdır. Örnek verecek olursak, yasal bir düzenleme ile kredi başvuru süreci değişen bir kurumda bu yasal düzenlemeye göre bir başvuru sürecini analiz etmek agile metotlarda çok anlamlı olmayabilir. Çünkü ihtiyaçlar nettir yapılacak işler bu ihtiyaca göre tek seferde analiz edilebilir.

İş analistleri de bu gerçeği göz önünde bulundurarak ölümüne Agilist olmamalıdır. Unutmamak gerekir ki her ilerleme önceki üzerine kurulmuş ve önceki metodun bir ürünüdür. Önceki metotlar da tamamen iptal olmaz ve işlevselliklerini yitirmezler.

HIGH LEVEL ESTIMATION (PROJE SÜRESİNİN TAHMİN EDİLMESİ)

HIGH LEVEL ESTIMATION

     Agile Metodoloji ile projelendirilen bir çalışmanın şüphesiz en önemli aşamalarından biri de bu projenin ne kadar süreceğini tahmin etmektir. Agile süreçte bu tahmin oldukça interaktif ve gerçeğe yakındır. Waterfall metodolojide, Ön analiz sürecinden sonra projenin ne kadar süreceği daha çok üst yönetim tarafından belirlenir. Yazılım ve Analiz konusunda her ne kadar ekipten yardım alındığı teorik olarak doğru olsa da pratikte yönetimin daha çok sorumlu olduğu bir konu olduğundan tecrübeli yöneticiler bu konuda aktif rol oynarlar.

    High Level Estimation, adından da anlaşılacağı üzere kesinlik ifade etmiyor. Tahmin yapılırken projenin "ne zaman biteceği" değil "ne zaman bitebilir" sorusunun cevabı aranmaktadır. Bu adım Iterasyon Zero diye adlandırılan Proje Hazırlık safhasında yapılır.  

KİMLER KATILIR? 

    Analist, Yazılımcı, Teknik Lider, Test Uzmanları, Test Lideri ile  Iterasyon Manager dahil projede görev alan tüm ekip katılır. 

NASIL YAPILIR?

Tahmin Kartları

    Bu adımda PRODUCT BACKLOG hazırdır. PRODUCT BACKLOG Tüm Story'lerin (Hikâye) listesidir bir anlamda. High Level Estimation yapılmadan önce tüm Hikâyeler kartlara yazılır. Bu işi ya Product Owner (PO) olarak görevli kişi yapar. Pratikte bu kişi BA olabilir. Bu kartlar fiziki kartlardır.

    Kartların Ön yüzünde Hikâyenin özeti, Arka yüzünde ise, ekibin tahmin ettiği Complexity-Zorluk seviyesi yazılır.

Tahmin Kartları

Tahmin Metotları: Complexity

    Kartlar sırasıyla ekibe gösterilir ve hikâyenin özeti anlatılır. Ardından tüm ekibe bu hikâyenin zorluk derecesini düşünmesi istenir. Ardından ekip aynı anda tahminlerini bir kağıda yazarak ya da parmakla göstererek kaldırır.

Tahmin için iki metot vardır. Hikâyeler en kolaydan en zora doğru bu şekilde sıralanır.

1. T-Shirt Size: XS,S,M,L,XL....:  Sayısal olarak ifade edilecek olursa S=1 derece iken her önceki ve sonraki zorluk öncekinin 2 katı zor ya da kolaydır. Bu durumda XS:0,5S  M:2S  L:4S zorluk düzeyindedir. Bu derecelendirmede XL ve daha büyük hikâyelerin çok komplex olduğu ve bu yüzden parçalanması ve zorluk düzeyinin azaltılması beklenir. 
2. Fibonacci Serisi: 1,2,3,5,8,13 olarak ilerler.  Burada doğrudan bir puanlama olduğu için tekrar bir dönüştürmeye ihtiyaç yoktur. Bu sınıflandırmada da 8 ve üzeri derecelendirilmiş hikâyenin çok komplex olduğu ve parçalanması gerektiği sonucu ortaya çıkar.

Tahmin yaparken tahmin edicilerin referans alacağı 2 önemli kıstas vardır.

• Birincisi, ilk hikâyenin zorluk derecesidir. Genellikle ilk hikâyeye orta düzey bir puanlama verilir. Bu da M ise diğerlerinin zorluk seviyesi buna göre düşünülerek verilir.
• Diğer kıstas ise Bir hikâye ekip tarafından bir iterasyon içerisinde bitirilebilecek kadar büyük olabilir. Bu da L veya 5 olarak derecelendirilir. Böylece bir iterasyonda bitirilemeyeceği düşünülen hikâyeler XL,XXL vb. bir derecelendirme alır. 

Eğer ekip içerisinde tahminlerde bir farklılık varsa tüm ekip uzlaşana kadar ekip kendi arasında niçin böyle bir tahmin yaptığını diğer ekibe anlatır.
Örneğin 4 kişi tahminleme yapmış olsun. Bunlardan çıkan sonuç aşağıdaki gibidir.

Müge : L
Murat : L
Selim : M
Ayhan :XL

    Burada Müge ve Murat benzer bir tahminleme yapmıştır. Fakat Selim ve Ayhan arasında ciddi bir fark vardır. Bu kişiler birbirini tahmin nedenlerini anlatır. Bu esnada daha ortak fikir sunan Müge ve Murat da bu fikirleri dinledikten sonra kendi fikirlerini söyler. Bu tartışmanın sonunda Selim de bu hikâyenin L olduğuna ikna olmuş ama Ayhan halen XL konusunda ısrar ediyorsa burada iki durum vardır. Ya Hikâyenin kapsamında bir sorun vardır ki bunu PO değerlendirmek zorundadır. Ya da ekip içerisindeki algılardan kaynaklıdır ve bunun için çoğunluğun fikrine uymak gereklidir.

    Bu tahminler alındıktan sonra her hikâyenin arkasına zorluk derecesi yazılır ve tüm hikâyeler bitene kadar bu işlem devam eder.

Takım Hızı: Velocity

    Her hikâyenin zorluk derecesi belli olduktan sonra takımın bir iterasyonda ne kadar zorluk düzeyinde iş çıkaracağını belirlemek gerekir. Öncelikle bir iterasyonun süresi belirlenir. Agile uygulanan kurumlar bu konuda bir standart kendilerine göre belirlerler. Bu kurum içerisinde bir iterasyonun 2 hafta olduğu varsayımında bulunarak devam edelim.

    Kartlar karıştırılır. Bu kartların toplam zorluk derecesinin 100S olduğunu düşünelim.
Bu kartlardan bir tane seçilir. Zorluk derecsi gösterilmeden takıma Hikâye anlatılır. "Bir iterasyon içerisinde takım olarak bu hikâyeyi bitirebilir misiniz?" diye sorulur. Takım evet derse bu hikâye iterasyona dahil edilir. Bu işlem takım "yeter" diyene kadar yapılır. Örneğin ilk turda takım 2 M, 2 L büyüklüğünde 4 hikâye seçmiş olsun. Bunların toplamı aşağıdaki gibi S'ye dönüştürülerek yazılır.Bu şekilde 5-10  arası tur yapılır. Bu turlar sonucunda takımın ortalama hızı ortaya çıkar. Aşağıdaki örnekte 6 tur yapılmış ve ortalama hız 11 S olarak ortaya çıkmıştır. Bu demek oluyor ki bu takım 1 iterasyonda 11S büyüklüğünde iş bitirebilir.

Velocity Hesaplama Tablosu

    Bu örneğe göre değerlendirecek olursak elimizde toplam 100 S zorluk derecesinde hikâye vardır. takımın hızı her bir iterasyon için 11S olduğundan takım bu projeyi 9 iterasyonda bitirebilir. Bu da 18 hafta olarak ilgili işin sahibine iletilir.

SONUÇ

Takım hızı ve Hikâye zorluğu sadece ilgili takım için geçerlidir. Takım değişirse, bu tahminler yeniden yapılmalıdır. Bir takımdan elde edilen sonuçlar kesinlikle başka takım için geçerli olamaz. 

STORY-HİKÂYE

Agile geliştirme süreçlerinden Scrum, Kanban, Lean, XP gibi herhangi birinin uygulandığı projelerde çalışan bir analistin en çok duyacağı, konuşacağı ve üzerine çalışacağı kavramlardan biri de STORY, Türkçesiyle ifade edecek olursak HİKÂYE’dir.

Klasik Analiz yöntemlerinde Hikâyenin tam karşılığı olmasa da yakın olarak anılan ifade edilebilecek birçok karşılığı vardır.  Kimi Fonksiyon, kimi Bileşen, kimi İhtiyaç, kimi de daha global ifadeyle Requirement derken, çoğu platformda da adına, doğrudan ANALİZ denir.

Agile süreçlerdeki kavramlar, Waterfall süreçlere göre daha belirgin çerçevelerle ifade edilir ve uygulama noktasında da daha kesin sınırarda ilerler. Bu anlamda HİKÂYE de Agile süreç içerisinde daha olgun ve ayakları yere basan bir kavram olarak karşımıza çıkar.

Hikâye: Projenin bir parçasıdır. Bu parça; en fazla bir iterasyon süresinde yapılabilecek kadar kısadır. Müşteri için katma değeri olup, tek başına bir ürün özelliği taşır.

Hikâye ve proje ilişkisini şöyle örnekleyecek olursak;

Bir müşteri inşaat firmasından 6 ayda kendisi için bir ev yapmasını ister. Fakat, müşteri, ev tamamlanmadan önce ayda bir kendisi için anlamlı ve tamamlanan bir parçayı görmek ister. Firma bu isteği karşılayabilmek için bir plan yapar. Projeyi 6 parçaya böler. İnşaat projelerinde işler nasıl parçalara bölünür bilmiyorum ama kabaca planı şöyle yapılmış olsun.

• Mimari Plan Tasarım: 1 ay
• Jeolojik araştırmalar: 1 ay
• Temel yapma: 1 ay
• Duvar örme: 1 ay
• Boya dekorasyon: 1 ay
• Anahtar Teslim:1 ay

Müşteri her ay sonunda projeye uygun parçaları görür ve gerekli bildirimlerini yapar. Böylece proje tamamlanmadan önce gerekirse revizyonlar ve projede güncellemeler yapılır.

Burada projeyi dilimlerine bölerken müşteri için anlamlı olması önemlidir. Örneğin Müşteri 2. ay projenin ne aşamada olduğunu görmek için geldiğinde Jeolojik Araştırmalar kendisi için hiçbir anlam ifade etmeyecekse burada müşteri tamamlanan ve kendisi için anlamlı bir parçayı göremez.  Bu yüzden Projede tamamlanan parçanın bir Değeri (Valuable) olmalıdır.

Hikâye Nasıl Oluşturulur:

Yazılım dünyası reel ekonomi dünyasının yardımcılığı görevini görür. Bir anlamda piyasa değiştiği için yazılım değişmek zorundadır. Yazılıma göre piyasa şekillenmez. Bu yüzden hız ve değişebilmek Yazılım dünyasında oldukça önemlidir.  Müşterinin taleplerinin her an yön değiştirebileceği hesaba katılmalıdır. Hikâyenin temelinde yatan asıl konu değişime adaptasyondur.

Hikâye oluşturmak diyoruz. Yazmak değil. Çünkü hikâye yazmak ve bir formata oturtmak işin en son ve Agile süreçler için daha az öncelikli kısımdır.

Hikâye oluşturulurken yukarıdaki ev örneğindeki gibi projenin müşteriye sunulabilir parçalara ayrılması gereklidir. Peki, bu parçalar nasıl belirlenmelidir. Projeyi Parçalara ayırdığımızda ortaya çıkan Hikâye oluşturmak özelde Analist ve genelde de Agile Takım’ın yetenekleriyle ilişkili olsa da bu süreç Bill Wake tarafından oluşturulan INVEST kuralına göre oluşturulmalıdır.[1]

INVEST

İngilizce Independence, Negotiable, Valuable, Estimetable, Sized(Small), Testable kelimelerinin baş harflerinden oluşan bu yöntem hikaye oluşturulurken oldukça yol göstericidir. Bu kavramları kısaca özetleyelim.

INDEPENDENT: Bağımsızlık ilkesi. Proje parçalarına ayrılırken her bir parça diğer bir parçanın bitmesine veya başlamasına mümkün olduğunca bağımlı olmamalıdır. Mümkün Olduğunca diyoruz çünkü yazılımda bunu tamamen sağlamak mümkün olmayabilir. Fakat hedef projeyi parçalarken aşağıdaki hunide her bir parça bağımsız bir şekilde proje havuzunu dolduran fonksiyonlar kümesine dökülmeli ve projede birikim oluşturabilmelidir.

Her bir Hikâyenin Projenin tamamlanmasında doğrudan Katkısı olmalıdır

NEGOTIABLE: Tartışılabilir, anlaşılabilir. Hikâye sadece Analist veya Product Owner insiyatifinde oluşturulamaz. Her bir hikâyenin projenin sponsoru, müşterisi ve yazılım ekibi tarafından kabul edilmesi ve üzerinde anlaşılması gerekir. Bu durumda sadece proje detayları üzerinde değil aynı zamanda Hikâye parçalarının oluşturulmasında da ilgili paydaşlar ile mutabakat sağlanmalıdır.

VALUABLE: Müşteri için değer ifade etmeli. Müşteri bir hikâyeyi proje ilerlerken ilgili iterasyonda tek başına görebilmeli ve buna göre bir karar alabilmelidir. Bu da en önemli ilkelerden biridir. Örneğin, Kurumsal Web Sitesi isteyen bir müşteriye için şöyle bir HIKÂYE anlam ifade eder mi? “Şirket kampanyaları için bir Web Servis oluşturulması”… Etmez. Müşteri sonuçta elinde bir işlev görmek ister ve bu işlevin ona bir anlam ifade etmesi gerekir. O zaman Valuable bir Hikâye şöyle olabilir mi diye tekrar soralım. “Müşteriler Şirketin Devam eden kampanyalarını anlık olarak görebilmelidir.” Evet bu kez oldu. Bu Hikâyeyi herhangi bir iterasyon anında müşteriye bir ekranda gösterebileceğiniz gibi Kampanya bölümü müşteri için değerli bir parçadır.

ESTIMETABLE: Tahmin edilebilmeli. Hikâye oluşturulurken bu hikâye için ne kadar kaynak ayrılması gerektiği önceden tahmin edilmesi gerekecektir. Bu yüzden bir Hikâyenin ne kadar yazılım, test ve diğer IT kaynaklarını meşgul edeceği ilk bakışta tahmin edilebilir olmalıdır.

SIZED-SMALL:  Yeterince Küçük olmalı. Müşteri için Değer ifade ettiği müddetçe Hikâye mümkün olduğu kadar küçük olmalıdır. Buradaki Kısıt Valuable ilkesine göre hareket etmektir.

Hikâye küçük olmazsa Kompleks ve Tahmin Edilemez bir hale gelebilir. Bir hikâyenin bu kurala uydurulabilmesi için Agile Projelerin INCEPTION adımında BACKLOG GROOMING işleminin yapılması oldukça faydalı olacaktır.

Hikâyenin Değer ve Tahmin Edilebilirliğine göre Hikaye Boyutu

TESTABLE: Test edilebilir olmalı. Hikâyede istenen fonksiyonlar net olmalı. Yoruma açık veya tartışılabilir olmamalı. Ayrıca Hikâyede testi mümkün kılmayacak fonksiyonlar içermemeli. Örneğin Web Sitesi tasarımında “İlk bakışta Kampanya bölümü göze çarpacak bir bölümde olmalıdır” gibi bir Hikâye muğlak bir ifadedir ve test edilemez. Bunun yerine “Kampanya Bölümü Ekranın üstünde bulunan Haberler bölümünün sağ tarafında bulunmalıdır” gibi bir ifade kullanılabilir.

Hikâye INVEST özellikleri taşımasının  yanında ayrıca  Rol/iş,aksiyon/sonuç olarak ifade edilebilmelidir. Bu daha çok Hikâye özetlendiğinde paydaşların hemen fikir edinebilmesi için bir anlamda Hikâyeyi özetleyen bir kalıptır. 

Örneğin internet sitesi tasarımı için şöyle bir Hikâye detaylarını bilmeden önce açıklayıcı olacaktır.

"Bireysel Müşteri olarak sisteme login olduğumda, siparişlerimin hangi aşamada olduğunu görmek istiyorum" 

Rol: Bireysel Müşteri

Aksiyon : Sisteme login olduğumda

Sonuç:  Siparişlerimin hangi aşamada olduğunu görmek istiyorum" 

---

[1] http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

Agile Süreçte İteratif Yaklaşım (ITERATION)

Agile metodolojide en sık kullanılan kavramlardan biri de "iterasyon"dur.

Diğer Adı Sprint olan iterasyon projenin parça parça müşteriye sunulması için tüm projenin birkaç adımda bağımsız oluşturulan her bir adımın adıdır.

Her bir iterasyonda, Takımın hız (VELOCTY)ve kapasitesine (CAPACITY) ile Story(HİKÂYE)’lerin Puanına (STORY POINT) bağlı olarak belirli sayıda Hikâye planlanır.

İterasyon 1 ile 4 hafta arasında sürebilir. Genellikle Salı ve Çarşamba günleri iterasyon başlar. Diğer günlerde başlanması pek tercih edilmez.

İterasyon süreci şöyle başlar: Başlangıçta İterasyon Planlama (Iteration Planning) toplantısı yapılır. Bu toplantıda Tüm Agile takım ve Product Owner veya Analist bulunur. Öncelikli Hikâyeler Kartlara yazılarak takıma gösterilir. Takım içerisindeki kişiler, bu kartlardaki bilgilere ve Product Owner'den aldığı bildirimlere göre hikâyeye kendi puanını verir. Takım bu puanlamaları yaptıktan sonra takımın hız/kapasitesini de düşünerek  bir veya birkaç Hikâye bitireceği sözünü verir. Bu Hikâye grubuna da SPRINT BACKLOG denir.

Bir iterasyonda sözü verilen Hikâyeler iterasyon sonunda yazılım-test-sign-off aşamalarını geçtikten sonra, diğer iterasyon başlamadan önce bitirilen iterasyon müşteriye sunulur. Sunum sırasında tüm Agile takım, Product Owner ve proje planlamasında bulunan kişiler bulunur. İterasyon içerisinde eksik yapılan veya yeni istenen talepler diğer iterasyonda yapılmak üzere yeniden hikâyelendirilir. 

İterasyon ve iterasyon planlamanın ana süreci aşağıdaki gibi özetlenebilir. Canım da ne mandalina çekti:)

İterasyon ve  Planlama Özeti

Burndown Chart

Agile projelerde ilerleme statüsünü gösteren grafiktir.

Bu grafik proje toolları ile elde edilebileceği gibi sürekli güncel tutulan bir excell yardımıyla da elde edilebilir.

Örnek:

2 Haftalık bir iterasyon planladığımızı ve Salı günü başlayıp 2 hafta sonra Salı günü sona ereceğini düşünelim.

Bu iterasyonda toplam 3 story ve toplam 80  Acceptance Criteria / Task olduğunu düşünelim. 

Planlamaya göre her gün ortalama 8 task bitirilecek ve 11 gün sonunda tüm tasklar bitirilecek.

Fakat her gün bitirilen tasklar girildiğinde 5 gün sonra aşağıdaki sonuç elde edilmiş olsun. 

Tablodan da anlaşılacağı üzere planlanan işler ile gerçekleşen işler arasında bir fark vardır. Bu fark aynı grafik üzerinde gösterildiğinde aşağıdaki gibi bir sonuç elde edilir. Planlama ve Actual eğime bakıldığında Actual eğim (task/gün) daha düşük olduğu ve planlamanın gerisinde olduğu anlaşılıyor. bu durumda taskların daha hızlı bitirilmesi ve planlamaya  yaklaşılması amaçlanarak kalan günlerde bu yönde bir efor harcanmalıdır. 

Agile Süreçlerde İhtiyaç Analizi Nasıl yapılır?

İş Analizinin yapılması, diğer bir deyişle “Analitik düşünceyi kullanarak ihtiyaçların analiz edilmesi” için gerek Waterfall gerekse Agile süreçler temel olarak aşağıdaki yöntemleri ortak kullanır.

-          Ön Analiz (Bilgi Toplama)
-          Süreç Analizi
-          İhtiyaç Analizi
-          Etki Analizi
-          Süreç Tasarım
-          İhtiyaç Detaylandırma

Temel Analiz araçları açısından Agile Süreçler ve Waterfall süreçler çok farklılık göstermez. Burada esas fark Agile Süreçlerde analiz yapılırken müşterinin taleplerinin her an değişebilmesi veya gelişebilmesi ihtimaline bağlı olarak, analizinin tek bir parça halinde değil küçük parçalar halinde Yazılıma verilmesi ve Analizin step by step yapılmasıdır.

Bir ailenin yıllık patates ihtiyacı ortalama 50 kilo diyelim. 50 kilo patatesi özenle seçip bir seferde almak veya her hafta 1 kilo patates almak, çok basit anlamda Waterfall ve Agile arasındaki farkı anlamamızı sağlar. 

Evet öngörülen tüketim miktarı 50 kilo olabilir. Ama yıl içerisinde Patates ile ilgili sağlığa zararlı haberleri çıkarsa veya Patatesin muadili olan diğer sebzeler aşırı ucuzlarsa veya Mutfakta patatesi bozacak bir ortam oluşup patatesler bozulacaksa, bu gibi nedenlerden dolayı tek seferde tüm patatesi almak ailenin büyük bir risk alması anlamına gelir.

Waterfall Delivery

Agile Delivery

Agile manifestonun 4 ilkesini hatırlayacak olursak, bunlardan biri de gereksiz dokümantasyondan kaçınmak idi. Dolayısıyla, Agile süreçlerde Analizden söz ederken Waterfall yöntemdeki gibi Detaylı bir Analiz Dokümantasyondan ve doküman şablonlarından bahsetmeyeceğiz. Agility, Dokümantasyonun tamamen gereksiz olduğu gibi bir tez ortaya atıyor gibi düşünmeyelim. (BKZ: [Agile & Dokümantasyon]) İhtiyaçları yazmak, doküman üzerinde uzlaşmak elbette gerekiyor. Agile süreçte esas olan dokümanın nasıl yazılacağı değil, Müşteri tarafından istenen ürünü beklenen nitelikte teslim edebilmektir.

            “İş Analisti Nasıl analiz yapar?” sorusunu yanıtlaman önce Agile süreçlerde İş Analisti ve Product Owner farkını anlatmaya çalışalım.

Product Owner, hem müşteri hem de iş analist rolünü üstlenir. Yani, hem ürünün içereceği ana fonksiyonları ve detaylarını müşteri adına belirler hem de bu ürüne ait detaylı iş analizini yapar. İş Analisti ise daha önceden müşteri tarafından tüm fonksiyonları belirlenen ürünün sadece analizini yapar.  Fakat Türkiye’de henüz bu yetkiye sahip özelleşmiş bir rol olmadığı için İş Analistleri bu rolü yavaş yavaş üstleneceklerdir. Bu rolü üstlenirken ilk etapta Prodcut owner gibi ürünün detayları müşteri adına kendisi belirlemeyecek, bu işi müşteri ile birlikte yapacak ama nihai kararı müşteri verecektir.

Gelelim Analize; Analiz yapılırken Agile manifestonun temel esasları unutulmamalıdır. (agilemanifesto.org) Doküman içinde boğulmamalı, analiz yaparken müşteri ile açık ve mümkün olduğu kadar fazla iletişime girilmelidir. Analiz yapılırken izlenen ana adımlar aşağıda belirtilmiştir. (Burda anlatılan Analiz kavramları Scrum Metodolojisinde kullanılır. Diğer Agile yöntemlerde de genellikle story-iterasyon mantığı ile parçalı (iteratif) analiz yöntemi kullanılır.)

-          İş analisti önce iş işbirimi ile ürün hakkında temel bilgileri toplar.
-         Üründen beklenen temel fonksiyonların detayları olmaksızın sadece ana fonksiyonları (STORY) çıkarılır.  (PRODUCT BACKLOG)
-          STORY öncelikleri belirlenir. (Önceliklendirme)
-          Önceliklendirilmiş story’lerden ilk ITERATION’da ihtiyaç analizi yapılacak olanlar belirlenir   (Sprint Backlog)
-          Storylere ait Kabul Kriterleri (Acceptence Criteria) belirlenir.
-          Tüm detayları ile hazırlanan STORY’ler yazılım ile paylaşılır.
-          Yazılım iterasyon süresince İş Analisti ile sürekli DESKCHECK yaparak doğru ilerlediğini teyit eder.
-          Iterasyon bittikten sonra yazılım yapılan çalışmaları Analist ve müşteriye gösterir. (SHOWCASE)
-          Bu iterasyon sonunda yeniden önceliklendirme yapılır varsa yeni yeni ihtiyaçlar için Change Request (CR)  STORY’LER çıkarılır.
-          Bir iterasyonun yazılımı devam ederken Analist sonraki iterasyona ait diğer öncelikli Storyleri detaylandırır.

 Bu süreçlerde kullanılan yöntemleri genel olarak aşağıdaki şekilde ifade edebiliriz.

İhtiyaç Analizi, İş Analizi Adımları

AGILE TAKIMIN ÖZELLİKLERİ

     Agile Manifesto’ da proje başarısı için en önemli unsurlardan biri doğru takım oluşturabilmektir. Agile takım bir projenin siparişi alma noktasından üretime almaya kadar her adımını bünyesinde sonuçlandıracak bireylere sahip olmalıdır. Burada bahsettiğimiz Takım yapısı sadece Scrum Metodolojisi  için değil Agile olan Kanban, Lean, XP (bunlar agile manifestonun farklı fakat aynı amaca odaklı süreç türleridir) gibi tüm süreç tipleri için geçerlidir.

Takım’ın kimlerden oluştuğundan bahsetmeden önce Agile bir Takım’ın öncelikli amacı yüksek etkileşimli takım-YET olabilmesi gerektiğini belirtmek gerekir. 

YET;

•  Birbiri ile uyumlu
•  Daima etkileşim içerisinde
• Soru ve sorunları face2face halleden
• Ekip ile bildiği her teknik bilgiyi Paylaşmaktan çekinmeyen
• Amaç birliği konusunda uzlaşmış
• Sonuca giden yolda Süreci tıkayabilecek her engeli aşmak için hiçbir iletişimden çekinmeyen
• Rekabetçi değil işbirlikçi (Bağcı döven değil üzüm yiyen)
• İş tahminleme yetenekleri gelişmiş
• Sonuca ulaşma adına gerekirse hızlıca farklı teknikler uygulayabilecek kadar esnek
• Öğrendiği bilgileri hızlıca uygulayabilen
• bireylerden oluşmalıdır.

Agile bir takım kimlerden oluşur?

1.    PRODUCT MANAGER (PRODUCT OWNER-PO): Bu kişi teknik ekip içerisinde ürünün sahibidir. Bu kişi tüm proje paydaşları (stakholders) adına tam yetkilendirilmiş kişidir.

Ürünün olgunlaşması, ürün vizyon ve beklentilerine göre yapılandırılması, Analiz çalışmasının yapılmasından sorumludur. PrdMngr’nin üvanının ne olduğu değil, fonksiyonu önemlidir. Fakat Waterfall metodolojide genel olarak İş Analisti olarak görev yapan kişiler bu görevi üstlenirler.

2.    PROGRAM MANAGER (PM): Takım’ın yöneticisidir. Scrum’da  SCRUM MASTER olarak adlandırılır. Bu yöneticinin klasik anlamdaki yönetim şeklinden farkı “katılımcı yöneticilik” özelliğidir. Takım kararları ortak verir. Program Manager, bu kararların uygulanıp uygulanmadığını takip eder, takım içi iletişimi yönetir, iş yükünün dengeli dağıtılmasını sağlar. Tarafsızdır ve çözüm üreten kişidir.

3.    TEKNİK MİMAR (ARCHITECT): Proje başlangıcında üründen beklenen ihtiyaçları PO’dan aldıktan sonra teknik mimari ihtiyaçlarını belirler. Bu proje için alternatif modeller üretir ve bu modeller arasında en uygun modeli ekiple beraber tartışarak seçer. Seçilen modelin projeye uygulanmasını sağlar ve sürekli modeli gözden geçirerek eksiklikleri giderir.

4.    YAZILIMCI (DEVELOPER): Ürünün implemente edilmesinden sorumludur. Developerler ayrıca story’lerin tahminlemesinden de doğrudan sorumludur. Her iterasyonun başında QA ve Developer ekibi o iterasyondaki potansiyel tüm storylerin zorluk derecelerini belirler ve hangilerinin o iterasyonda yapılacağına doğrudan karar verir.

5.    Quality Assurance-QA (Test Uzmanı): Projenin her iterasyonunda ortaya çıkacak ürün parçasının (Sprint Backlog) beklenen özellikleri karşıladığını teyit eder. Bu amaçla PO tarafından beklenen her bir Kabul Kriteri (Acceptance Criteria) için Test senaryolarını yazar.  Test senaryoları tüm kabul kriterlerini kapsamalıdır. QA testleri geçtikten sonra PO sadece Sign-off testi yapar. Sign-Off, QA testi kadar kapsamlı olmayıp daha önce planlanmış ve yazılmış senaryoları yoktur. Bu yüzden asıl defectlerin bulunduğu yer QA testleridir.

6.    USER EXPERIENCE DESIGNER (UED):  PO sadece ihtiyaçları belirler. Gerekirse görsel açıdan yardımcı olması için mock-up’lar hazırlayabilir. Fakat kullanıcının alışkanlıklarını ve trendleri bilen ve bu ihtiyaçlara göre User Interface tasarımları yapan kişi PO değildir. Bu görevi UED yerine getirir. PO ile görüşerek ürün özelliklerini netleştirdikten sonra alternatifler üretir ve PO ile nihai tasarıma karar verir.

Takımın büyüklüğüne bağlı olarak Program Manager, UED ve Architect rolü başka rollere atanabilir. Fakat bir ekipte Developer, QA ve PO her durumda ayrıca bulunmak zorundadır.

Takım oluşturmada kesin bir ölçüt olmamakla beraber 5-20 arasında değişebilir. Fakat önemli olan PO, DEV, QA dağılımını doğru yapmaktır.

PO/Dev/QA oranı genellikle 1/3/1 veya 1/3/2 olarak optimize edilir.
Bu oran aşağıdaki durumlara göre değişkenlik gösterir

• Kullanılan test yöntemi: Otomatik? Manuel? 
• QA alışkanlıkları nedir? Manuel Test mi Otomatik Test mi?
• Deployment süreci
• Kullanılan teknoloji ve Developerlerin bu teknolojilerle çalışması
• SDLC süreci

Fakat Agile bir takım için tercih edilen genel oran 1/3/1’dir. Test maliyetlerinin yükselmesi her ne kadar istenmese de Production ortamlarda minimum hata için gerektiğinde QA sayısında artışın olması olağandır ve bu yüzden QA oranı PO ve DEV ekibine göre daha esnek hale getirilebilir. 

Agile ve Dökümantasyon

1. KISA KISA 

• Agile için önemli olan iletişimdir. Dokümantasyon değil
• Dokümantasyonda yenilikçi olmak gerek. Araştırmak ve kullanıcı taleplerine göre format değiştirmek gerekir.
• Dokümantasyonun maliyeti vardır. Bu maliyet hesaplanmalı ve birileri tarafından üstlenilmelidir.
• İyi yazılmış bir doküman proje boyunca iletişim için zayıf bir yöntem olsa da, güçlü bir kurumsal hafıza için gereklidir.
• Dokümanlar kısa ve öz olmalıdır. Dokümanda genel açıklamalar ve roadmap'lar detaylı açıklamalardan daha etkindir. 
• Birçok doküman tipi vardır. Bu dokümanlardan ihtiyaçları karşılayacak kısmı seçilmeli. Ne eksik ne de fazla. İhtiyaçlar konusunda iyi analiz yapılmalı.
• Dokümantasyon mükemmel değil olması gerekenin en asgarisi kadar iyi olmalı.
• Kapsamlı doküman projenin başarısını arttırmaz. Azaltması bile muhtemeldir
• Agile takımının öncelikli hedefi yazılımı tamamlamaktır. Dokümantasyon ikinci hedeftir.
• Dokümantasyon yaparken fayda maliyet analizi göz önünde bulundurulmalıdır.
• Dokümantasyon ihtiyacı her sistemde aynı değildir. Bu yüzden her kurum ve sistem için gerektiğinde farklı dokümanlar üretilmelidir.
• Dokümantasyon ihtiyaç mı, yoksa sadece yapılması mı isteniyor? İhtiyaç olan dokümanlar üretilmeli. İstenenlerin maliyetine katlanmamak gerekir.
• Doküman ihtiyaçlarına Teknik ekip değil kurum karar vermelidir.
• Dokümantasyon sistemini her zaman değil, probleme neden olacağı düşünüldüğü zaman güncel tutmak gerekir.

2. DOKÜMANTASYON YAPILMASININ NEDENLERİ?

TEORİK NEDENLER:

Proje Sahiplerinin İhtiyacı: Projeyi talep eden iş birimleri ihtiyaçları doğrultusunda dokümanları talep ederler. Teknik ekip bu ihtiyaçlara göre doküman üretmek zorundadır.

Proje Sözleşmesi : Bazı Projelerde sözleşme gereği bazı dokümanlar zorunlu hale gelir. Örneğin iletişimin yazılı olması gereken veya bağlayıcılık taşıyan projelerde dokümanlar proje sahiplerinin talebine göre hazırlanmalıdır.

Kurumsal Hafızayı Geliştirmek: Dokümantasyon ve versiyonlama kurumun geçmişte yaptığı tüm projelerin detaylarıyla izlenebildiği bir sistem olması yönüyle İş sahipleri tarafından istenir.

Denetim: Bazı kuruluşlarda denetim ve gözetim amaçlı dokümantasyon gereklidir.

Doğrulama: Hem Proje sahiplerine hem de yazılım ekibinin aynı şeyi anlayıp yaptığını teyit etmek ve detayları inceleyerek varsa eksik kalan kısım tamamlamak amaçlı dokümantasyona ihtiyaç duyulur.

PERDE ARKASI NEDENLER

Talep Sahiplerinin Kontrol İsteği: Talep sahipleri projenin tüm süreçlerinde Devam ya da Dur aksiyonlarını verebilmek için dokümanlarla süreci izlemek ve kontrol altında isterler. Bunun yanı sıra yönetime karşı işin yapıldığını ve sürecin kontrol altında olduğu hissi öğretildiğinden yönetim tarafından da genelde dokümantasyon olmazsa olmaz çıktılardandır.

Talep Sahiplerinin Algısında Dokümantasyonun Başarıya götüren etmenlerden biri olması vardır. Bu da tamamen yanlıştır. Oysa aşağıda yayınlanan Rapora göre (2005-2006 Standish Group Chaos Report) proje başarısında dokümanın etkinliğinin sanıldığı gibi bir etkisi yoktur.

Alışkanlıklar: Birçok IT organizasyonunda Waterfall yöntemiyle proje yapıldığından en sonda projeye ilişkin detaylı bir doküman beklentisi vardır. Bu beklentinin nedeni ise proje sonunda iş sahiplerinin  testlerini yapmasından ve proje hakkında yeterli fikir sahibi olmamalarından kaynaklı bir iletişim eksikliğidir.

Outsource Kontrol: Birçok IT organizasyonunda işlerin bir kısmı Outsource edilmektedir. Bu yüzden birçok kurumlar kontratların içeriğine doğal olarak bazı dokümantasyon talepleri eklenmektedir. Bu da yatırım yapılan iş için yeterli düzeyde çalışma yapılıp yapılmadığını kontrol etmek içindir.

Garantiye Alma Gereksinimi: Proje sahipleri genellikle iç ve dış yönetime karşı yaptıklarını belgelemek amacıyla doküman üretirler.

3. BİR DOKÜMAN NASIL AGILE OLUR?

Dokümantasyon Agile manifestoda istenmeyen bir yapı değildir. Fakat dokümantasyon önemli bir süreç olmakla beraber bazı esaslar üzerine oturmalıdır.

1. ROI (Return of Invest) 'yi Maksimize eder: Dokümanın bir maliyeti olduğu gerçeğinden hareketle, Doküman maliyeti üstlenen iş birimlerine maksimum faydayı sağlamalıdır. 
2. Maliyetler Bilinmelidir: Maliyeti üstlenen iş birimleri, dokümantasyonun maliyetini bilmeli ve yatırım yapmalı mı kararını onlar vermelidir. 
3. Kısa ve Yeterli Olmalı: Bir doküman refere ettiği sistemi asgari düzeyde açıklayabilir detayda ve mümkün olabildiğince kısa  olmalıdır. Dokümanda başka detaylara ilişkin bilgiler varsa referans verilmeli. Doküman oluştururken kendimizi düşünelim. Kaç kez yeni bir sürüm veya sistem hakkında doküman inceledik. Diyelim ki cevabınız olumlu. Peki kaçında tüm detayları buldunuz, kaçı size "iyi ki bu doküman var ve inceledim" dedirtti. Bu yüzden dokümanlar oluşturulurken mükemmel olmasına değil yeterli olmasına önem verilmelidir.
4.  Tek bir amaca yönelik olmalı: Bir doküman sadece bir amaca göre yazılmış olmalı. Farklı doküman tipleri birleştirilerek tek doküman haline getirilmemeli.Örneğin; Release Note, User Manuel tek dokümana indirgenmemeli veya birbiriyle ilişkili diye farklı sistemler aynı dokümanda açıklanmamalı. 
5. Doküman bir üründür ve müşterisi vardır:  Agile doküman aynen ortaya çıkan ürün gibi başlı başına bir üründür ve bu ürünü kullanacak müşteriler vardır. Müşterinin üründen maksimum faydayı alması hedeflenmelidir. Sistemi kullanacak müşteriler, Sistemi kullanan kişilerin yöneticileri, Sisteme bakım yapacak teknik kişiler ayrı ayrı müşterilerdir. Dokümantasyon yapılırken her bir kitleye özelleşmiş ve sadece o kitleyi ilgilendiren bölümler ayrıştırılmalıdır. 
6. Pareto İlkesi: Sistemin %80 oranda kullanılacak bölümleri tüm sistemin %20'sini teşkil eder. Bu pareto ilkesi birçok IT sisteminde de geçerlidir. Bu yüzden Doküman tüm sistem içerisinde "bilinmesi özellikle gereken" bölümleri ayrıca belirtmeli  ve ROI (Return Of Invest) kuralına göre daha düşük maliyetle yüksek faydalar sağlamalıdır. 
7. Versiyonlama: Dokümantasyon yapıldıktan sonra en maliyetli ve belki de kısımlardan biri de dokümana süreklilik kazandırmaktır. Eğer doküman bir kez oluşturulup arşive atılıyor ve yapılan değişiklikler doküman üzerinde versiyonlanmıyorsa bu dokümantasyon dinamik değildir ve sağladığı fayda eğrisi düşer. 

4. DOKÜMAN TİPLERİ 

Gerek agile gerekse waterfall metodolojide ihtiyaç duyulacak bazı doküman tipleri aşağıda listelenmiştir. Bunlardan hangisinin ihtiyaç olduğu ve hangisinin maliyetinin üstleneceği konusu talep eden işkollarına göre değişiklik gösterebilir. Fakat konsolide dokümanlardan daha ziyade her biri farklı amaca göre yazılmış ve ayrıştırılmış dokümanlar tercih edilmelidir. 

	Doküman Tipi	Kimin İçin	Tanımı
1.	Contract Model	Sistemle ilişkili olan dış takımlar	Mevcutta çalışan bir sistemin (legacy system) teknik yapısını açıklayan dokümandır.
2.	Design Decisions / Tasarım Kararları	Yazılım, Destek, Proje Yönetim Ekibi	Takımın Yazılım sürecinde mimari ve sistem tasarım üzerine aldığı temel kararların tutulduğu doküman
3.	Executive Summary / Yönetici Özeti	Yönetim Grubu	Çalışmanın fayda, maliyet ve temel fonksiyonlarını içeren oldukça kısa ve çalışmayı özetleyen dokümandır.
4.	Project Overview / Proje Genel Tanıtım	Tüm Teknik Ekipler	Projenin teknik ve iş ihtiyaçlarının temel noktalarını özetle anlatan kısa ve proje ihtiyaçları değiştiğinde güncel tutulması gereken dokümandır.
5.	Analiz Dokümanı / Requirement Document	Yazılım, Destek, Proje Yönetim Ekibi, Kullanıcılar ve İşkolları	Çalışmanın yapılacağı sistemdeki fonksiyonaliteleri açıklayan içerisinde süreç, usecase, UI Prototip ve ihtiyaçların detaylarını barındıran dokümandır.  Waterfall projelerde bu doküman projenin başında yazılır ve çok önemli bir sözleşme niteliğindedir. Proje sonuna kadar revizyon olması beklenen ama mümkün olduğunca kısıtlı değişiklikler yapılabilen dokümandır. Agile yöntemlerde bu doküman iteratif oluşturulur ve proje sonuna kadar sürekli olgunlaşır.
6.	Support Document / Destek Dokümanı	Destek Ekibi	Proje bittikten sonra proje ile ilgili her türlü desteği verecek olan HelpDesk, SupportDesk vb  ekiplerin sistemi tanıması için hazırlanan ve çıkabilecek sorunları,çözüm yöntemlerini ve sık karşılaşılabilecek soruları yanıtlayan bir dokümandır.
7.	Sistem Dokümantasyon	Yazılım ve  Sistem Destek Ekibi	Bu doküman aslında tüm sistemin temel işlevleri (Requirements), veritabanı yapısı, Servis bağlantıları, Kullanılan teknoloji ve toollar, güvenlik ve altyapı konularında detaylı açıklamalar içerir. Burada temel fikir şudur. Eğer çalışmayı yapan ekipten biri işten ayrılır ya da başına birşey gelirse diğer ekip elemanları onun görevini yerine getirebilecek kadar bilgiyi bu doküman ile sağlamalı ve yoluna devam etmelidir. dolayısıyla bu tür dokümanlar daha çok kritik ve daha kapsamlı projelerde oluşturulur.
8.	Kullanıcı Klavuzu / User Manual	Kullanıcılar	Sisteme giriş, sistemi kullanma, sistem içerisinde kullanıcıya sunulan işlevlerin anlatıldığı ve karşılaşılan temel soru ve sorunların cevaplandığı teknik içeriği olmayan dokümanlardır.

ÖZETLE....

Agile manifesto hatasız ve  piyasa koşullarına hızlı adapte olabilen proje üretmek amacını güder. Bu yüzden asıl enerji bu alanlarda harcanmalıdır. Dokümantasyon Agile yöntemde de sürecin bir parçası olsa bile, dokümantasyonun proje başarısına ciddi bir katkısı olmadığı düşünülmekte fakat gerekli olmadığı iddia edilmemektedir.Yani, Agile süreçlerde Doküman oluşturulmalı fakat mümkün olduğunca otomatik ve ihtiyacı karşılayabilecek minimum detayda oluşturulmalıdır.

YAŞASIN İ(N)TERA(K)TİF PROJE GELİŞTİRME...

* http://www.agilemodeling.com

Agile Nedir?

WATERFALL YÖNTEMİ

Agile nedir cevabını vermeden önce "Waterfall nedir?" sorusunun cevabını verelim. 
Waterfall şelale demek oluyor İngilizce'de. Yazılım geliştirme dünyasında ise bir projenin tüm parçalarının tek seferde analiz edilmesi, kodlanması ve test edilerek devreye alınmasıdır. 

Örnek verecek olursak, (rakamlar farazidir. Analiz, yazılım ve test sürelerinin oranı her projede değişebilir) Ali Bey LTD şirketi tüm nakliyat bilgilerini yöneteceği bir sistem istediyse projenin planlaması 2 hafta, analizi 2 ay, yazılımı 1,5 ay ve testleri 1 ay olarak planlanır.  

Bu durumda Ali Bey Ltd. taleplerini tüm detaylarıyla ilk 1-2 ay içerisinde Analist ile netleştirmek zorundadır. Yazılımcı bu projeye planlamaya göre 2,5 ay sonra, test sorumlusu 4 ay sonra başlar. Projenin analizleri bitmiş iken ve yazılımı devam ederken Ali Bey şirketi ara ara olmak üzere irili ufaklı 10-15 talep/değişiklik talep etmiş olsun.İşte bu noktada tüm analiz dokümanlarının yeniden güncellenmesi ve kodların gözden geçirilmesi gerekir. Bu da tüm proje ekibinin hiç hoşlanmadığı bir durumdur ki bunun temel nedeni Waterfall yönteminin değişikliklere hızlı adapte olamamasıdır. Yani Çevik değildir. Waterfall yönteminde proje yönetimi aşağıdaki gibi taşımaya benzer.

Waterfall Proje Metodolojisinden bir kesit

Kaza anında da durum aşağıdaki gibidir tabii :)

Waterfall Proje Risklerinden bir kesit

Agile kavramını duymamış neredeyse tüm analistlerin ve yazılımcıların ve tabii ki birçok banka, telekom ve finans kurumunun Türkiye'de uyguladığı yazılım geliştirme metodolojisidir.

AGILE YÖNTEMİ

Agile bir manifestodur. Bu manifestonun her ne kadar yapılandırılmamış ta olsa daha önceye dayanan bir tarihi olsa da 2001 yılında Kent Beck öncülüğündeki 17 kişinin bir araya gelerek  ilkelerini oluşturdukları bir proje geliştirme felsefesidir. Esasını 4 temel Madde oluşturur. Bu maddelerin altında 12 ilke vardır. (agilemanifesto.org)

Özetle şöyle der,

• Takım Çalışması yapın.
• Değişiklikleri kolayca projeye implemente etmek gerekir. 
• Dokümanlarda boğulmayın. 
• Ürün sahibi ile sıkı fıkı olun.

Agile ile Scrum da ayrıca karıştırılmamalıdır. Agile deyince Scrum akla gelebilir ama Scrum, Agile manifestoya uygun olarak geliştirilen bir metodolojidir. Felsefesi Agile olup kendine göre pratikler geliştirmiştir. Scrum gibi XP,Kanban, RUP, Lean gibi Agile metodolojiler de vardır. 

Deneyimsel olarak Agile Yöntemi ifade edecek olursak; Egolardan arındırılmış bir takımın Müşterinin isteklerine hızlıca cevap vererek Yazılım Süreçlerini Hızlı Değişen rekabetçi Piyasaya adapte edebilmesidir.

Ali Bey Ltd projesini Agile Manifesto ilkelerine göre yapılandırılmış SCRUM METOD ile oluşturmaya çalışarak AGILE ve WATERFALL arasındaki bir kıyas yapabiliriz. 

(SCRUM Süreci ileride detaylandırmak için bu sürece ilişkin bazı kavramları Büyük Başlık ile belirttim. Eğer üzerinde link varsa demek ki açıklamışız. Ama link yoksa ölmesek yazacağız :))

  

1. Önce tüm talepler özetle alınır ve 2 hafta içerisinde proje planlaması kabaca yapılır. Bu kısım waterfall ile benzerlik gösterir.
2. Planlamada ürün ana parçalara bölünür. EPIC (Uzun hikaye demek).  
3. Bu EPIC'ler INVEST  ( Independent, Negotiable,Valuable,Estimatable,Small,Testable) parçalardan oluşan STORY'lere bölünür. Bu olaya BACKLOG GROOMING denir ve İş Analisti ile Agile Takımın bir araya gelmesi ile Analistin öncülüğünde ile yapılır. Bu kısım planlama esnasında yapılır fakat STORY detaylarına inilmez. 
4. Tüm Story'ler PRODUCT BACKLOG'u oluşturur. 
5. Daha sonra STORY'ler önceliklendirilir. Önceliklendirmeyi İş Analisti, PROJE PAYDAŞLARI (STAKEHOLDERS) olan Product Owner (İşi isteyen kişi), AGILE TAKIM lideri, teknik takım lideri ile birlikte yapar.  
6. Önceliklendirmeden sonra HIGH LEVEL ESTIMATION (HLE) yapılır. HLE sonunda bu işin 5 ayda 8 ITERATION'da biteceği sonucuna varılır.Iteration1,Iteration2,......Iteration8. Herbir itaration 2-4 hafta arasında sürer herbiri bir veya daha fazla EPIC'ten oluşur.
7.  Iteration(n)'in başlaması için Iteration(n-1) adımında Analist, Iteration(n) EPIC'lerine ait STORY'leri detaylandırır. Detayları Product Owner ile belirler ve her bir story ACCEPTANCE CRITERIA (AC)'lardan oluşur. 
8. Her bir iterasyon yazılım, test, SIGN-OFF, Product Owner Testi (SHOWCASE) ve deployment sürecinden oluşur.
9. Her iterasyonun başında İş Analisti Story'lerin detaylarını takım ile paylaşır. Yazılım ve test ekibi geri bildirimlerini yapar.
10. Bir iterasyonda yapılan işlerin kapsamı kesinlikle değiştirilemez. değişiklik gerekirse yeni bir story yazılır ve yeniden önceliklenidrme yapılarak başka bir iterasyonda yapılır.
11. Her iterasyon sonunda Agile Takım iterasyonu ve genel gidişatı değerlendirir.
12. Iterasyon devam ederken her sabah takımın tüm üyeleri "önceki gün ne yapıldı", "bugün ne yapılacak", "bloklayan durum var mı" şeklinde kısa feedback'lar verir. Sorunlar ortaya atılarak takımla çözülür.
13. Her iterasyon sonunda İş Analisti ortaya çıkan Story'leri PO'ya sunar ve geri bildirimleri varsa bu bildirimlere göre yeni STORY'ler yazar ve bu iterasyonu kapatır.