Agile, Scrum ve Bilgi Mimarisi
Proje yönetiminde Agile ve Scrum kullanıyorsanız, aşağıdaki başlıkları mutlaka iyi anlamalısınız. Aynı zamanda bu bilgiler iş analistleri için olmazsa olmaz bilgiler…
- Tema (Theme), Destanlar (Epics), Kullanıcı Hikayeleri (User Stories), Görevler (Tasks). Peki ne anlama gelirler?
Bir işin analizinde, projenin bilgi mimarisi oluşturulurken herkesin kendince bir yöntemi vardır. Ancak PMI, Prince2, Agile, Scrum gibi yapılar bunları belirli isimlendirme standartlarına oturtmuştur. Projelerde herkesin aynı dili konuşması adına bu isimlendirmeler oldukça önemlidir. Scrum da bilgi mimarisindeki kırılımları Tema, Destanlar, Kullanıcı Hikayeleri, Görevler şeklinde adlandırmıştır.
Bilgi mimarisi dediğimiz şey en basit haliyle, ana yapının parçalarına bölünerek yönetilmesidir. Bir de şöyle bir örnek var:
Gerçek hayattaki Scrum döngüsünde, Ürün Sahibi (Product Owner), Ürün İş Listesi’ni (Product Backlog) oluştururken, tüm paydaşlara proje için “NE” gerekli olduğu sorusunu sorarak isterleri toplar. Bu “NE” sorusuna gelen her bir cevabı “Özellik” olarak ele alıp, en iyi şekilde anlayıp, özellikleri birbirleri ile ilişkilendirmeye başlar. İlişkilendirilen bu özelliklerden aynı olanlar (farklı şekilde ifade edilmiş) teke düşürülüp paketlenerek İstek Listesileri’ni (Wish List), destanları (epic), kullanıcı hikayelerini (user stories), görevleri (tasks) oluşturur.
Şimdi gelin bu adlandırmaları madde madde açıklayalım.
Tema (Theme)
Modül veya pencere isimleri olarak da görülebilirler.
Örnek:
- Ana Sayfa
- Hakkımızda
- Toplu Email Gönderme Modülü
Destanlar (Epics)
Bir sprint’e sığmayacak kadar büyük bir şey, müşteri gereksinimleri açısından açıkça anlaşılmamış şeylerdir. Destanlar sprintlere sokulmazlar. Bunlara süper kullanıcı hikayeleri de diyebiliriz. :) Ürün sahibi (Product Owner) tarafından belirlenir. Destanlar genellikle ilk ürün yol haritası sırasında tanımlanır ve konu anlaşıldıkça kullanıcı hikayelerine ayrıştırılır. Yazılım sürümlerini aşan bir başlıkdır aynı zamanda.
Bir Destan genel olarak en az iki sprint de tamamlanabilecek büyüklükte bir iş puanlamasına sahiptir.
Örnek:
Bir ürün sahibi (Product Owner) gereksinimlere bir epic ekliyor.
- “ Bir müşteri olarak, daha sonra ürün almaya geri dönebilmek için istek listelerine (wishlist) sahip olmak istiyorum. ””.
Kullanıcı Hikayeleri (User Stories)
Kullanıcı hikayeleri, PMI’ın Proje Yönetim döngüsündeki Kullanım Senaryosu (Use Case) ile ilişkilendirebilirsiniz. Aralarında nüanslar bulunmasına rağmen, temelde ikisi de paydaşların ihtiyaçlarının toplanıp, projeye girdi olarak sunulması amacına hizmet eder. Use Case bu işi, Aktor ve roller yardımı ile UML üzerinden yaparken; Kullanıcı Hikayeleri, işini cümleler üzerinden yapmayı tercih eder.
Bir sprint’e sığacak kadar küçük ve yapılabilir birşeydir. Ürün sahibi (Product Owner) tarafından belirlenir. Bunlar INVEST kriterlerini kullanarak, yapılandırılmış hikayelerdir. Kullanıcı hikayeleri genellikle ürün geliştirme süreci boyunca yaratılır, bu sayede sprint iterasyonu planlamasına ve aynı zamanda daha üst düzey ürün yol haritasına geçilir. Tek bir sprinte sığabilir. Kullanıcı hikayesi olarak tanımlanan bir yapının, çok fazla task’ı varsa, bu yapı destan (epics) olabilir.
Bir kullanıcı hikayesi, kendisine bağlı olan tüm görevler bittiğinde biter.
Kullanıcı Hikayeleri istenilen her formatta oluşturulabilir. Product Owner’ın PBI ları rahatça çıkarabilmesi amacı ile tercih edilen kabul görmüş aşağıdaki şablon, Sprint Planlama Toplantısına da eksiksiz girdi sağlamaya yardımcı olacaktır.
“[Kullanıcı Tipi] olarak, [neden/sebep] yapabileceğim bir sisteme [istek/ihtiyaç] duyuyorum.”
Burada kullanıcı tipinin belirtilmesindeki amaç, unvana göre işin ele alınması değil; gereksinimin, sistemi kullanacak hangi kullanıcı tipine hizmet edeceğini görebilmektir. “iş takipçisi”, “son onaycı”, “destek personeli” gibi rolün yapacağı işi belirten kullanıcı tipleri, işin doğru şekilde ele alınmasında fayda sağlayacaktır.
Örnek:
- Bir çalışan olarak IK’daki en son haberleri web sayfamdan görmek istiyorum, böylece neler olup bittiğini bilebilirim.
- Bir çalışan olarak, İK içindeki tüm kişilerin iletişim isimlerini bilmek istiyorum, böylece bir sorum olduğunda kimin telefon edeceğini / e-posta alacağını bilebilirim.
- Bir çalışan olarak, politikayı takip ettiğimden emin olmak için İK politika belgelerine erişmek istiyorum.
- Rapor uzmanı olarak, verileri kolaylıkla bulabilmek için, listeler içerisinde arama fonksiyonuna ihtiyacım var.
Görevler (Tasks)
Görevleri bir hikayeyi tamamlamak için yapmanız gereken günlük işler olarak adlandırabiliriz. Parçalara ayrılan kullanıcı hikayelerinin nasıl yapılacağının belirlendiği aşamadır. Görevler, telefon görüşmeleri yapmak, e-posta yazmak veya toplantı yapmak gibi nispeten az çaba harcayan bireysel çalışma öğeleridir.
Görevler genelde işi yapacak kişiler (yazılım geliştiriciler, tasarımcılar) tarafından tanımlanır. Görevler kısa ömürlü oldukları için, genelde sprint iterasyonlarında oluşturulabilir.
Bu aşamada yapılacak iş saat olarak tahmin edilebilmektedir. Her bir görev 30 dakika ile 3 gün arasında iş yükü olabilir. Görev’lerin; projenin geliştirilme, kabul ve teslim basamaklarındaki “DONE” kriterlerini oluşturan en küçük yapı taşı olduğunu söyleyebiliriz.
Örnek:
- Basit bir ana sayfa tasarımı oluşturun
- Ana sayfa için şirketin tasarım kriterlerine uyan bir css şablonu oluşturun
- İK ekibi tarafından düzenlenebilecek bir dosyanın kullanıcı tarafından web sayfasından indirilebilmesini sağlayın.
Bu bilgiler aşağıdaki adreslerden ve kullanıcı yorumlarından tercüme edilip düzenlenmiştir.
