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