Agile (Çevik) yöntemler ve bunlardan en yaygın olanı Scrum hakkında artık birçok yazı bulabiliyoruz. Bu yazıların çoğu ise teorik bilgi ile sınırlı kalıyor maalesef. Fakat okuyucunun beklentisi, Agile yöntemlerin nasıl uyarlanması gerektiğinin anlatıldığı yazılar oluyor.  Bu yazı dizisinde projelerimizde Scrum’ın sadece tanım ve aktörlerini değil, ayrıca Scrum nedir, pratikteki kullanımını nasıldır gibi soruların yanıtlarını bulacaksınız. 

Scrum Nedir?

Scrum en çok bilinen Agile framework’üdür. Agile çalışan şirketlerin yaklaşık %70’i Scrum uygular veya Scrum ile diğer Agile yöntemlerini birleştirerek hibrit bir uyarlama ile çalışır.

Agile ve Scrum’ın aynı şey olmadığını bilmek gerekir. Agile, birçok framework ve metodolojiden oluşan bir kavramdır. Scrum ise bu framework’lerden yanlızca bir tanesidir. Başka bir deyişle Scrum, gerçek dünyada Agile çalışmanın bir yoludur.

Agile yaklaşımın beraberinde getirdiği bazı metodlar:

Scrum: 90’ların sonlarından bu güne bilinen ve uygulanan çok basit (simple) ve hafif (lightwight) bir framwork’tür. – Scrum Nedir?

DSDM: (Dynamic Systems Development Method) Scrum ile aynı zamanlarda çıkmıştır. PRINCE2 ile uyumlu olması için tasarlanmıştır.

XP: (eXtreme Programming) 1999’dan beri en çok bilinen Agile uygulamalardan biridir. Daha çok pair programming ve test-driven development odaklıdır.

Kanban: Genellikle üretim/imalat alanında kullanılan bir yöntemdir. Agile yaklaşımı ile adaptasyonunda ise ScrumBan olarak karşımıza çıkar.

Scrum vs Kanban

Agile Nedir?

“Agile” tanımlaması yapılırken en önemli keyword kuşkusuz ki “Adaptive” dir. Çevik olmak, predictive (tahmini) bir sistem yerine, adaptive (uyarlanabilir) bir sistemi kullanmayı gerektirir.

Yazılım geliştirme sürecinde seçilecek olan yöntem belirlenirken, bu iki sistemin birbirinden farkını bilmeli ve ona uygun bir yöntem seçilmelidir.

Predictive Development

Geliştirilecek ürünün özellikleri tam olarak biliniyor ve tanımlanabiliyorsa, geliştirme süreci önceden öngörülüp planlanabilir. Geliştirme sırasında da o plana uygun hareket ederek ürünü çıkma hedefine ulaşırız. Bu geleneksel bir yöntem olan “Waterfall” modelidir.

Peki neden bazı projelerde tahminleme yapamıyoruz? Bu durumda ne yapmamız gerekir?

Adaptation

Günümüzde uyarlanabilir (adaptive) proje geliştirme artık Agile yöntemler ile özdeşleşmiştir. Çünkü adaptive sistemler Agile geliştirmenin temelini oluşturur.  Projelerde tahminleme yapamadığımız zaman, uyarlanabilir bir sistem kullanarak o büyük açığı ortadan kaldırabiliriz.

Adaptive sistemlerde, “Değişiklik Yönetimi” (Change Management) önemli bir yer tutar.  Geleneksel bir proje yöneticisi planı asgari değişikliklerle takip etmeye odaklanırken, çevik bir lider kaçınılmaz değişikliklerde başarılı bir şekilde adapte olmalıdır.

Adaptive sistemler, “Geri Bildirim”e (Customer Feedback) yönelik çalışma şeklini beraberinde getirir. Geleneksel yöneticiler hedefi proje planı olarak görüken, çevik liderler müşteri değerini hedef olarak görmelidir. Böylece müşterileden gelen feedback’lere göre projeyi uyarlamak gerekir.

Gelen her geri bildirimin projeye uyarlanması bir döngü çerçevesinde gerçekleştirilir. Bu geri bildirimler bir sonraki döngünün çıktısı/sonucu olarak değerlendirilir ve o döngü içerisinde geliştirilmesi hedeflenir.

Scrum’da Projeye Başlamak

Hangi metodoloji olursa olsun, projeye start veren şey ürünün ihtiyaç listesidir. Scrum’da da projeye ürünün gereksinim listesi yani Product Backlog hazırlamak ile başlanır. Bu liste, proje/ürün için düşünülen özelliklerin listesidir. Ürün kapsamı olarak da değerlendirebiliriz.

Agile yöntemlererin adaptive çalışmasından bahsetmiştik. Scrum da predictive bir geliştirme yöntemi olmadığı için ürünün bütün özelliklerini gün 1’de belirlemek olanaksızdır. Bu yüzden proje başlangıcında Product Backlog’u önümüzdeki birkaç döngü (Sprint) için hazırlamak yeterli olacaktır. Proje ilerledikçe gelen feedback ve/veya ihtiyaçlara göre Product Backlog geliştirilir böylece adaptive geliştirme de sağlanmış olur.

Agile ilkelerinden biri de sadeliktir (Simplicity). Bu yüzden de Product Backlog, bir tool kullanılmadan, fiziksel bir tahtada oluşturulması tercih edilir. Genellikle kartlar veya sticky notlar kullanılarak backlog itemlar bu tahta üzerinde tutulur.

Product Backlog (Ürün Gereksinimleri)

Product Backlog içinde hangi ögeler (Items) olması gerekir diye düşünüldüğünde en çok sorulan soru “Product Backlog’da yazılım mimarisi için kayıt açılmalı mı?” oluyor genlede.

Cevap HAYIR! Bu durum predictive proje geliştirme bakış açısıdır. Ürünün iterative bir şekilde tasarlanması gerekir.

Product Backlog içinde sadece ürün özellikleri (Functions) olması gerekir. Sadece, müşterinin anlayabileceği, üretildiğinde kullanabileceği ve üzerine geri bildirim yapabileceği fonksiyonlar bu listede olmalıdır.

Product Backlog ögelerinin özelliklerini şöyle sıralayabiliriz:

• Ögeler teknik olmayan (Non-Technical) özelliklerden oluşmalıdır.
  Proje geliştirme süresinde iletişimde olduğumuz müşteriler genellikle teknik olmayan kişilerden oluşur. Çevik geliştirilen bir ürünün, tanımı/kapsamı için sayfalarca dokuman yazmak yerine daha sade ve anlaşılır onlan Product Backlog listesi paylaşılır. Bu yüzden Product Backlog’da müşterilen anlayabileceği teknik olmayan ögeler olmalıdır.

• Ögeler birbirinden bağımsız olmalıdır.
  Product Backlog ögeleri, ürün özelliklerinin iş değerine (Business Value) göre sıralanır. Ürün için önemli olan özellikler, Product Backlog listesinde üst sıralarda yer alır. Böylece odaklanılması gereken öge listeye bakar bakılmaz belli olacaktır. Ögelerin birbirinden bağımsız olarak tanımlanması da bu sıralamanın kolayca yapılabilmesini sağlayacaktır.

Tüm bu özellikler, Product Backlog ögelerinin anlaşılabilir olması için tasarlanmıştır. Bu ögelerin yazılması için kullanılan yöntem ise onları kullanıcı hikayeleri (User Stories) şeklinde yazmaktır.

User Stories (Kullanıcı Hikayeleri)

Agile geliştirilen ürünlerde, ürün gereksinimlerini belirtmenin en basit ve anlaşılıt yolu, onları kullanıcı hikayeleri şeklinde yazmaktır. Bu hikayeler ile ilgili ürün özelliğinin kim tarafından, hangi ihtiacı karşılamak için ne yapması gerektiği tek bir cümle ile belirtilir.

Ögeleri hikayeleştirmekteki amaç, ürün özelliğinin kullanıcı ile olan etkileşimini gerçek hayattaki gibi simule etmektir. Böylece kullanıcı, ürün geliştirildiğinde hangi ürün özelliğini kullanabileceğini kolayca anlamış olacaktır.

As a role, I want function, [so that purpose]

Şablondaki “amaç (purpose)” bölümü isteğe bağlı olarak yazılır. Rol ve ürün özelliği belirtildiğinde her şey belirgin ve anlaşlıyorsa bu ölümü yazmaya gerek yoktur.

Birkaç örnek vermek gerekirse;

Örnek 1: Amaç belirterek yazılan bir user story

“As an end user, I want to get a report on my account activity, to check if everything is OK.”

“”Son kullanıcı olarak, her şeyin yolunda olduğunu kontrol etmek için, hesap etkinliğime ilişkin bir rapor almak istiyorum.”

Örnek 2: Amaç belirtmeye gerek olmayan bir user story

“As a system administrator, I want to reset passwords.”

“Bir sistem yöneticisi olarak, şifreleri sıfırlamak istiyorum.”

Örnek 3:

“As a system administrator, I want to have an SQL database for the system.”

“Bir sistem yöneticisi olarak, sistem için bir SQL veritabanına sahip olmak istiyorum.”

Örnek 3’teki örnek UserStory’ler için yanlış bir örnektir. Kullanıcı hikayelerinin ikinci bölümü bir eylem ile ilgilidir. Yapılacak olan aksiyonu anlatmalı, sahip olunması gereken ihtiyaçları değil.

Peki Product Backlog ögeleri olan User Story’leri kim hazırlar?

Product Owner (Ürün Sahibi)

Product Backlog öğelerinin oluşturulmasından ürün sahibi Product Owner sorumludur. Bir projede yalnızca bir PO olmalıdır. Bu kişi tam zamanlı veya yarı zamanlı olabilir. PO işi en iyi bilen ve/veya iş odaklı çalışan (business-oriented) bir kişi olmalıdır. İş biriminden bir kişi veya nitelikli bir iş analisti bu rol için iyi bir adaydır.

–  PO rolündeki iş analistlerinin görevleri içeren yazıya buradan ulaşabilirsiniz. “Scrum’da İş Analistinin Rolü” – 

PO müşteri ile sürekli temas halindedir. Böylece gereksinimlerini anlar ve onları User Storiy’ler halinde Product Backlog ögeleri haline getirir. Ardından PO, her bir öğeye bir değer (Business Value) atar. Bu değer ile ürünün önemli özelliileri ortaya çıkmış olur ve Product Backlog listesinde bu değere göre özellikler sıralır. En üstteki öğeler en değerli olanlardır ve bir sonraki Sprint’te geliştirilecektir.

Bu yazı dizisine ait tüm bölümlere aşağıdaki linklerden ulaşabilirsiniz:

• Scrum Farkındalığı ve Uyarlanması Part 1: Scrum Nedir?
• Scrum Farkındalığı ve Uyarlanması Part 2: Sprint ve Ögeleri
• Scrum Farkındalığı ve Uyarlanması Part 3: Scrum Rolleri
• Scrum Farkındalığı ve Uyarlanması Part 4: Scrum Development
• Scrum Farkındalığı ve Uyarlanması Part 5: Scrum Çıktıları (Outputs)

İlkim Dilara KADAKALOĞLU