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.