Laba’da 28 Şubat tarihinde başlayacak Agile İş Analizi online eğitimi öncesinde Intertech’in Mimar İş Analisti Tolga Demirli ile Agile İş Analizi üzerine keyifle okuyacağınız bir röportaj gerçekleştirdik.
Son dönemde Agile anlayışın Waterfall (Geleneksel) yaklaşımlara oranla daha çok tercih edilmesinin en önemli gerekçeleri nelerdir?
Dünya genelinde özellikle teknolojinin hızlı bir şekilde gelişmesi ile birlikte içinde bulunduğumuz dönem VUCA (Volatilite, Uncertainty, Complexity, Ambiguity) dönemi olarak adlandırılmaktadır. Bu dönemi değişkenlik, belirsizlik, karmaşıklık ve muğlaklık kavramlarının daha etkin olduğu bir dönem olarak düşünebiliriz.
Değişimin bu kadar etkin olduğu bir dönemde ihtiyaçlar çok hızlı değişmekte ve yeni ihtiyaçlar ortaya çıkabilmektedir. Geleneksel (Waterfall) proje anlayışında da gereksinimlerde değişimler olmakta ve yönetilmektedir. Fakat çoğu zaman değişim sonucu ortaya çıkan yeni ihtiyaçlar, gereksinimler bir sonraki fazlara adreslenmekte ve sürekli bitmeyen, birbirini takip eden fazlar, projeler karşımıza çıkmaktadır.
Waterfall yönteminde yazılım geliştirme süreci belli safhalardan (Analiz, Tasarım, Kodlama, Test, Entegrasyon) oluşmakta ve bir safha bitmeden diğerine başlanılmamaktadır. Büyük ve karmaşık projelerde geliştirmenin müşteriye teslim edilmesi uzun sürebilmektedir.
Bu süre zarfında ihtiyacın farklılaşması veya yeni ihtiyaçların ortaya çıkabilmesi çok olasıdır. Ayrıca safhalar ilerledikçe ortaya çıkan değişim ihtiyacının maliyeti çok daha fazla olabilmektedir.
Bu yüzden büyük ve karmaşık projelerde geleneksel anlayış yerine Agile (Çevik) anlayış ile değişimlere hızlı adapte olabilmek ve değişim yaratabilmek gerekmektedir. En küçük ürün parçası (MVP) müşteriye olabildiğince erken teslim edilmeli ve müşteriden olabildiğince erken geribildirim alınmalıdır.
Geribildirim sonucu erken öğrenme ve yeniden geliştirme çok daha mümkün olacaktır. Dolayısıyla karmaşık ve uzun sürebilecek projelerde Agile anlayış geleneksel (Waterfall) yönteme kıyasla daha fazla tercih edilmektedir.
Anlayış (Mindset) olarak değişmemiz ve çevik olmamız gerekli ve önemli bir konudur. Fakat bu durum Agile yaklaşımın geleneksel yöntemlerden her zaman daha iyi olduğu anlamına gelmemektedir.
Kısa sürebilecek, yasal, karmaşık olmayan, herkes tarafından anlaşılır ve net talepler Waterfall metodu kullanılarak yönetilebilir. “Agile > Waterfall” olarak düşünmemek ve ihtiyaca uygun yöntemi kullanmamız gerekmektedir.
Agile projelerde iş analizi aktivitelerinin ve iş analistinin önemi hakkında bilgi verebilir misiniz?
Bu noktada temel iki tanımın üzerinden geçmekte fayda olduğunu düşünüyorum. IIBA tanımına göre iş analizi,
“Organizasyonel bağlam içerisinde ihtiyaçların tanımlanması ve paydaşlara değer katacak çözümün belirlenmesi yoluyla değişimin gerçekleşmesini sağlayan pratikler bütünüdür.”
olarak tanımlanmaktadır. İş analizi pratiklerini gerçekleştiren profesyoneller de İş Analisti olarak adlandırılmaktadır. Bazı yayınlarda, çalışmalarda Agile anlayış ile birlikte İş Analisti diye bir pozisyon, ihtiyaç olmayacağı yönünde görüşler var. Bu görüşü benimseyen, savunan insanların aslında İş Analisti pozisyonunun sorumluluklarını, görevlerini bilmediğini düşünüyorum.
Aslında biz iş analistlerinin de kendimizi çok iyi anlatamadığımızı düşünüyorum. İş analistliği, maalesef uzun zaman boyunca müşteri ile yazılımcı arasındaki köprü olarak tanımlandı. Bu pozisyondaki insanlar genelde toplantı notlarını tutan ve paylaşan, geliştirmeleri test eden, doküman yazan kişi olarak görüldü. Fakat IIBA iş analizi tanımında da belirtildiği gibi iş analistinin görevi aslında müşterinin ihtiyacına değer katacak en uygun çözümü bulmaktır.
Çevik olmanın, ihtiyacın doğru ve hızlı bir şekilde anlaşılmasının öneminden bahsetmiştik. Değişen dünyada doğru çözümün hızlı bir şekilde belirlenmesi ve uygulanması gerekmektedir. Bu yüzden Agile dünyada iş analizi yetilerinin, mesleğinin daha fazla önem kazanacağını ve değerli olacağını düşünüyorum.
Agile iş analizi ilkeleri nelerdir? Agile projelerde iş analizi yaparken dikkat etmemiz gereken noktalar nelerdir?
BABOK Guide V3 kitabına ek olarak çıkan Agile Extension dokümanında aşağıdaki ilkeler belirtilmiştir.
- Bütünü Görmek: İhtiyacı ve değişimi en geniş bağlamda değerlendirmek gerekir. Büyük resmi görmek önemlidir.
- Müşteri Gibi Düşünmek: Müşteri gibi düşünmeyi öğrenmemiz, müşteri ihtiyaçlarını anlamamız gerekmektedir. Geribildirim ve öğrenme esas alınarak sürekli iyileşme hedeflenmelidir.
- Değerli Olanı Belirlemek: Teslim edilen ürün parçacığının değerinin maksimize edilmesi gerekmektedir. Değerli olan iş önceliklendirilmelidir.
- Yapılabilir Olanı Anlamak: Mevcut kısıtları görerek çözümün gerçekleşme ihtimali değerlendirilmelidir. Takım kapasitesi ve enerjisi yapılabilir olan işlere harcanmalıdır.
- İşbirliğini Teşvik Etmek & Sürekli Gelişme: İhtiyaç sahibi kullanıcılar ile çözüm sunan ekipler arasında işbirliği sağlanmalıdır. Hem ürün hem de ekip olarak sürekli gelişme esas alınmalıdır.
- İsraftan Kaçınmak: Değer katmayacak aktivitelerden kaçınılmalıdır. Değer katan ama ihtiyacı tam karşılamayan aktiviteler azaltılmalıdır. Değer katan aktiviteler öncelikli olarak gerçekleştirilmelidir.
- Örnekler Kullanarak Gerçekçi Olmak: İhtiyaç ve çözümü karşılıklı anlamak için gerçekçi örnekler kullanmak önemlidir. Tüm paydaşlar için ortak dil ve anlayışın kurulması gerekmektedir.
İş analisti olarak Agile projelere başlarken öncelikle hangi soruları sormalıyız?
Projelere başlamadan önce aşağıdaki sorular mutlaka sorulmalı ve atlanmamalıdır.
- Neden? – İş ihtiyacını anlamak, mevcut işleyişi ve hedeflenen yapıyı öğrenmek önemlidir. İş gereksinimlerinin ortaya çıkarılması olarak da düşünülebilir.
- Kim? – Projelerin başarısız olmasının en önemli nedenlerinden biri paydaşların atlanmasıdır. Kullanıcılar ve paydaşların not edilmesi, atlanmaması için önemlidir.
- Ne? – Kullanıcı ve paydaş gözüyle taleplerin çıkarılması gerekmektedir. Kullanıcı gereksinimlerinin ortaya çıkarılması olarak da düşünülebilir.
- Nasıl? – Çözümün nasıl sağlanacağının belirlenmesi açısından önemlidir. Fonksiyonel ve fonksiyonel olmayan gereksinimler, iş kuralları, varsayımlar öğrenilecektir. Çözüm gereksinimlerinin ortaya çıkarılması olarak da düşünülebilir.
Agile projelerde talep ve gereksinim yönetimi nasıl sağlanır?
Agile projelerde gereksinimler anlamlı ve değerli parçalara bölünerek yönetilmelidir. Bu parçalar boyutlarına ve işlevlerine göre Initiative, Epic, Story olarak adlandırılabilir. Tamamlanan ürün parçacıkları müşterilere teslim edildikçe alınan geribildirim ile gereksinimler yeniden değerlendirilerek parçalara ayrılabilir. Detayları örnekler ile aşağıda bulabilirsiniz.
- Initiative: Şirketin stratejik hedefleri doğrultusunda tasarlanan, planlanan projelerin üst seviyede tanımıdır. Örnek: Kullanıcıların alışveriş deneyimini iyileştirmek
- Epic: Tek başına yapılamayacak kadar büyük, anlamlı alt parçalara bölünebilecek karmaşık iş ve projeler bütününe denir. Örnek: Kullanıcılar için ürün beğenme özelliği, favori yapısı oluşturulması
- Story (Kullanıcı Hikayesi): Kullanıcı perspektifinden belirlenmiş, geliştirmesi bir sprint içerisinde tamamlanabilecek gereksinimlerdir. Örnek: Kullanıcıların favorilere aldığı ürünlerden koleksiyon oluşturabilmesi, beğendiği ürünleri paylaşabilmesi, beğendiği ürünlere benzer ürünleri listelemesi
İyi bir kullanıcı hikayesi yazarken nelere dikkat etmeliyiz?
İyi bir kullanıcı hikayesi INVEST tekniğine göre yazılmış olmalıdır.
- Independent: Kullanıcı hikayeleri birbirinden bağımsız olmalıdır. Ayrı ayrı geliştirilebilmeli, test edilebilmeli ve teslim edilebilmelidir.
- Negotiable: Ürün ekibi ve iş birimleri ilgili kullanıcı hikayesi üzerinde tartışabilmelidir.
- Valuable: Kullanıcıya, ürüne değer katabilmelidir. Bu madde en önemli özelliklerden biridir. Kullanıcıya değer katmayan bir kullanıcı hikayesi mümkün değildir.
- Estimable: Tahmin edilebilir olmalıdır. Ürün ekibi ilgili kullanıcı hikayesinin büyüklüğü hakkında tahmin yürütebilmelidir.
- Small: tek bir sprint içerisinde tamamlanabilecek kadar küçük olmalıdır. Birden çok gereksinim içerdiği takdirde alt hikayelere bölünebilir.
- Testable: İlgili kullanıcı hikayesinin test edilebilir olması gerekmektedir.
Agile projelerde çalışırken karşımıza nasıl sorunlar çıkabilir? Bu sorunları ortadan kaldırmak için neler yapabiliriz?
Agile projelerde paydaş yönetimi konusunda sorunlar yaşanabilmektedir. Bu sorunların ortadan kaldırılması için paydaşların iyi analiz edilmesi ve yönetilmesi gerekmektedir. Öncelikle projeye başlarken ve gereksinimler toplanırken hiçbir paydaşın atlanmadığında emin olmalıyız. Paydaşların ihtiyaçları doğrultusunda bilgilendirme yapıları, mekanizmaları geliştirilmelidir.
Örneğin, Sprint Review toplantıları geribildirim alınması noktasında önemli etkinliklerdir. Fakat Review toplantılarını beklemeden de müşteri, paydaşlar ile her zaman iletişimde kalmalı ve sürekli işbirliği içerisinde olmalıyız. İş birimi ile aynı gemide bulunduğumuzu unutmamalı ve ürün vizyonu çerçevesinde birlikte hareket etmeliyiz.
Paydaş yönetimi dışında dokümantasyon seviyesi ve yönetiminde sorunlar yaşanabilmektedir. Agile yaklaşımda mevcut “Lightweight Documentation” konsepti dokümantasyona önem verilmediği olarak algılanmamalıdır. İhtiyacı ve gereksinimi anlayacak, çözümü aktarabilecek kadar - ihtiyaç halinde yeteri kadar da diyebiliriz - dokümantasyon anlayışı benimsenmelidir.
Örnek vermek gerekirse kullanıcı hikayeleri tekniği ile yazılan gereksinimler bir araya getirerek gereksinimler toplanabilir ve dokümante edilebilir.
Kullanıcı kılavuzları veya uzun kapsam dokümanları yerine son dönemde Ürün Dokümanları kullanılmaktadır. Ürün vizyonu, hedefleri, modülleri ve özellikleri bir dokümanda tutulmaktadır. Bu doküman oluşturulurken canlı ortamda karşılaşılabilecek kullanıcı senaryoları (use case) temel alınmalıdır.
Canlı bir doküman olduğu, her etkileyen proje sonucunda ilgili bölümlerin güncellenmesi gerektiği unutulmamalıdır. Son olarak ihtiyaç sahibi ve çözüm üreten ekiplerin ortak dili konuşabilmesi ve anlaşabilmesi adına akış, diyagram, ekran tasarımı gibi görsel öğeler hazırlanmalı ve dokümante edilmelidir.
