Product Owner’ın 37 Görevi
Bu makalemizde Product Owner rolünün görevlerini detaylandırılmış bir şekilde inceleyeceğiz. Bunların içinde ürünün değerini en yükseğe çıkarmadan tutunda, ürünün pazarlama süreçlerine kadar geniş bir bilgi sahibi olması gerektiğini göreceğiz. Product Owner’ın 37 Görevi aşağıdaki gibidir.
Scrum Master rolünün tam zamanlı bir iş olup olmadığı sürekli sorgulansa da Product Owner rolü neredeyse hiç sorgulanmaz. Bir istisna dışında; Roman PICHLER, Agile Product Management With Scrum adlı kitabında The Partial Product Owner -Kısmi Ürün Sahibini- anlatır.
Deneyimlerime göre birçok Product Owner işlerine yoğunlaşma problemi yaşamaktadır. Product Owner’lar, Scrum Takımı içinde geliştirmeleri gereken, ürünle doğrudan ilişkili olmayan ve birçok taahhüt ve sorumluluk gerektiren özel bir departmanın parçası gibidirler.
Product Owner’lık tam zamanlı bir iştir. Aşağıda Product Owner’ın işinin parçası diyebileceğim 37 görev bulunmaktadır. Bu görevlerin Development Team’le beraber yapılması gerekir.
NE Sorusu
- Ürün vizyonunu geliştirme ve adapte etme.
- Yeni kullanıcı hikayeleri hazırlama.
- Çok büyük olan kullanıcı hikayelerini bölme.
- Her kullanıcı hikayesi için Acceptance Criteria belirleme.
- Kabul testlerini yazma.
- Product Backlog’u önceliklendirme.
- Release planlaması yapma.
- Product Backlog’u iyileştirme, INVEST ve DEEP kriterlerini uygulama.
INVEST Kriteri Nedir?
I Independent / Bağımsız: Başka bir kullanıcı hikayesi ile ilişkili ya da onun mirası şeklinde olmamalı.
N Negotiable / Tartışılabilir: Kullanıcı hikayeleri, bir sürümün parçalarıdır ve her zaman değiştirilebilirler ve yeniden yazılabilirler.
V Valuable / Değerli: Bir kullanıcı hikayesi son kullanıcı için değerli olmalıdır.
E Estimable / Tahmin Edilebilir: Kullanıcı hikayesinin büyüklüğünü her zaman tahmin edebilir olmalısınız.
S Sized appropriately or Small / Uygun Büyüklükte ya da Küçük: Kullanıcı hikayeleri planlaması, görevlendirmesi ve öncelik belirlenmesini zorlaştıracak ya da imkansız hale getirecek kadar büyük olmamalıdır.
T Testable / Test edilebilir: Kullanıcı hikayesi test yapılabilmesini sağlayacak gerekli bilgileri sağlamalıdır.
DEEP Kriteri Nedir?
D Detailed Appropriately / Uygun şekilde detaylandırma: Product Backlog’taki kullanıcı hikayeleri yeterince anlaşılabilir olmalı ki gelecek Sprint’te tamamlanabilsinler. Az detaylandırılmış kullanıcı hikayeleri geliştirmek uzun sürecektir.
E Estimated / Tahmin Edilmiş: Product Backlog bitirilecek işlerin listesi olmasından öte kullanışlı bir planlama aracıdır. Çünkü Product Backlog’ta aşağı sıralarda bulunan maddeler iyi anlaşılmadığında onları tahmin etmek listede üst sıralarda olan maddelere göre daha zor olacaktır.
E Emergent / Acil: Product Backlog statik değildir, zamanla değişecektir. Daha fazla öğrenildikçe Product Backlog’a yeni kullanıcı hikâyeleri eklenecek, var olanlar çıkarılacak ya da öncelik sıraları değişecektir.
P Prioritized / Önceliklendirilmiş: Product Backlog’ta en önemli madde en üstte, önemi düşük maddeler altta olacak şekilde sıralandırılmalıdır. Takım öncelik sırasına göre çalışarak ürünün değerini en yükseğe çıkarmayı başarabilecektir.
Dışarıda
- Pazarı gözlemleme, öğrenme ve analiz etme.
- Müşterileri ve ürünün son kullanıcılarını gözlemleme, öğrenme ve analiz etme.
- Proje sahipleri ya da proje destekçileriyle ile düzenli olarak iletişim halinde bulunma.
- Yönetime ve proje destekçilerine raporlar sunma.
- Kurum ile ürün hakkındaki düşüncelerini ve sezgilerini paylaşma, bloglar, sunumlar ve kurum içi konferanslar düzenleme.
Liderlik
- Neyin geliştirilip neyin geliştirilmeyeceğine karar verme.
- Development Team’e geri dönüşler yapma.
- Sprint boyunca geliştirilecek ürün hakkında
- Development Team’in süreçleri ve etkileşimleri hakkında
- Gemba Walk gerçekleştirme. Gemba, Genba olarakta kullanılır, buradaki anlamı bir değerin oluşturulduğu yerdir. Gemba Yürüyüşü ise işin gerçekleştirildiği yere gidip, işi burada yönetmektir.
- Development Team’e, iş maliyetlerini düşürmek için tek-tıkla-dağıtımın önemini açıklama ve bunu talep etme.
- Development Team’e, hızlı geri bildirimde bulunabilmesi için 10 Minute Build’in önemini anlatma ve bunu talep etme.
- Development Team’e, esnekliği koruyabilmek için Feature Flag’in önemini anlatma ve bunu talep etme.
- Development Team’e, ürünle ilgili her tür rakamı sağlama ve öğretme. Böylece ürün ve müşteriler ile Development Team arasında bağ kurma ve Development Team’le bilgilendirilmiş bir şekilde kararlar verebilme.
Katılım
- Scrum toplantılarına katılma.
- Sprint Planlaması için Sprint Hedefini ve yeni kullanıcı hikayeleri sağlama.
- Sprint Review toplantısında Sprint Hedefi’nin başarısına dair bilgi verme.
- Sprint Retrospective toplantısında takım üyesi olarak geri bildirimler verme ve buna göre aksiyon alma.
- Daily Scrum toplantılarında bilgilendirme, yardım etme ve Sprint’in gidişatı ile ilgili bilgilenme işlerini gerçekleştirme.
- Development Team’e süreçlerini geliştirebilmeleri için devamlı olarak yardımcı olma.
Öğrenme
- Agile hakkında her şeyi öğrenmeyi sürdürme. Örneğin, kullanıcı gruplarını ziyaret etmek, konferanslara katılma, kitap okuma, blog yazma.
- Kurum içindeki diğer Product Owner’larla bilgi alışverişinde bulunma.
- Ürünü kullanmak ve kullanarak ürün hakkında daha çok şey öğrenme.
- Ürünün tüm değer akışını öğrenme ve iyileştirme, tedarik, pazarlama ve satış akışı gibi…
- İlerlemeyi ölçme, her Sprint’te müşteriye teslim edilen değerin farkında olma.
Diğer
- Bilgi paylaşımını yaygınlaştırması için takıma yardımcı olma. Örneğin, insanlar çalışırken ya da yanından yürürken görebilecekleri bir duvara proje hakkındaki gelişmeleri yazma. Böylece kişiler birbirinin çalışmasını daha az bölerek daha çok bilgi sahibi olurlar.
- Müşterileri memnun etme.
- Uygun bir BİTTİ tanımı bulma.
- Uygun bir HAZIR tanımı bulma.
- Ürünle ilgili geri bildirim döngüsünü sıklaştırma. Örneğin, Daha sık ve daha erken release, müşterilerle konuşma.
- Fikirleri, ürüne çevirmek, mümkünse MVP(Minimum Viable Product – Minimum Uygulanabilir Ürün).
Yukarıda bahsedilen her şeyi yaptınız mı? Takımınızla berabersiniz ve ürününüz büyük bir başarı elde etti mi?
Mükemmel! Dışarı çıkın, kendinize ve takımıza büyük bir parti verin!
Kaynak: http://agiletrail.com
“Development Team’e, iş maliyetlerini düşürmek için tek-tıkla-dağıtımın önemini açıklama ve bunu talep etme.”
Kısmını anlayamadım. Tam olarak neyi kastediyor
“one-click-deploy” ile release maliyetlerini düşürmeyi vurguluyor. One Click Deployment için bu slayt daha detaylı bilgi verecektir.