Yani, 12 bölümden sonra, oyundaki daha somut unsurlar hakkında yazmaya başladım.
"Ürün İş Listesi, üründe ihtiyaç duyulduğu bilinen her şeyin sıralı bir listesidir." - Scrum Kılavuzu
Ürün İş Listesi, gerçekleşmemiş (potansiyel) değeri şeffaf hale getirir. Olmak değer. Ürün İş Listesi, Ürün Sahibi'nin alanıdır. Ürün Sahibi, Değer Maksimize Edici olarak , Geliştirme Takımının yaptığı işten kaynaklanan ürünün değerini maksimize etmekten sorumludur. Bu, Ürün İş Listesini kullanan tek kişinin Ürün Sahibi olduğu anlamına gelmez. Aslında, Scrum Takımı, Ürün İş Listesinin tek tüketicisi değildir. Değeri maksimize etmek için ihtiyaç duyulan seviyeye kadar şeffaf olması gerekir.
'Buzdağının ucu' metafor klişesini kullanmak uygunsuz değil . Ürün İş Listesi, yalnızca ekibin odaklanması gereken en değerli şeylerin görünür ve şeffaf olmasını sağlama işini yapmalıdır. Ürün Sahibi, bulanık sularda, değerli derin deniz gizemlerini keşfetmek ve bunları yüzeye çıkarmak için oldukça fazla zaman harcıyor.
Bir Geliştirme Ekibine karmaşık veya kaotik ortamlarda çalışmak için yapılandırılmış ve şeffaf girdi sağlayabildiği için Ürün İş Listesine kişisel olarak değer vermeye başladım. Bununla birlikte, çoğu durumda, Ürün İstek Listesi düzgün bir şekilde yönetilmediğinde / iyileştirilmediğinde, kuruluşun durumunu yansıtan dağınık bir kargaşa haline gelebilir. Bir Ürün İş Listesi, organizasyon, Ürün Sahibinin kişiliği hakkında çok şey ortaya çıkarabilir ve hatta potansiyel adam kayırmayla ilgili ipucu verebilir. Genel olarak elektronik tablolarda veya Jira gibi dijital araçlarda bulunan Ürün Bekleme Listelerinin ilk kez denetlenmesi genellikle sinir bozucu oluyor .
Artık Ürün İstek Listesi içeriği, Ürün İş Listesi kalemlerinde (PBI) düzenlenmiştir. Birçoğu bunlara Kullanıcı Hikayeleri diyor , ancak bunlar tamamen aynı şey değil. Her ne kadar Kullanıcı Hikayeleri (Extreme Programming kaynaklı), yaygın Scrum Ekipleri tarafından kullanılmaktadır, bunlar Scrum Framework bir parçası değildir. Bir PBI, Kullanıcı Hikayelerini veya gerekli olduğu bilinen herhangi bir şeyi içerebilir. Ancak Scrum Kılavuzunun gerçekte hangi nitelikleri içermesi gerektiğini anlattığı şey burada.
Ürün İş Listesi kalemleri bir açıklama, sıra, tahmin ve değer özelliklerine sahiptir.
Bunlar, gelecekteki sürümler için özellikler, işlevler, gereksinimler, geliştirmeler ve düzeltmelerle ilgili olabilir. Dolayısıyla, Ürün İstek Listesi ile ilgili sık sorulan sorulardan birini yanıtlamak için… evet, bunlar da düzeltmeler içermelidir ! genellikle orijinal Hata / Kusur Raporu ile birlikte.
İyi bir raporun özellikleri şunlardır:
"Ürün İş Listesi maddeleri genellikle " Tamamlandığında "eksiksiz olduğunu kanıtlayacak test açıklamaları içerir . - Scrum Kılavuzu.
Kimsenin kafasını karıştırmamak için… bunlar “Bitti” nin tanımları DEĞİLDİR. Ekiplerin bir PBI'ye özgü belirli Savunma Bakanlığı'na sahip olacağı birçok örnekle karşılaştım. "Bitti" tanımları genel Ürün Parçası için geçerlidir (ve dolayısıyla bu artış için üzerinde çalışılan tüm PBI'lar için). Bununla birlikte, test açıklamaları PBI'lara özel olabilir. Çoğu ekip, test açıklamalarına Kabul Kriterleri veya Kabul Testleri olarak atıfta bulunacaktır . Bunlar, çok özel koşulları / karşılanması gereken ihtiyaçları tanımlar. Yazılım Geliştirmede, bu testler PBI gerçekleşmeden önce oluşturulabilir; Kabul Testi Güdümlü Geliştirme adlı bir uygulama.
"ATDD (Kabul Testine Dayalı Geliştirme):
yeni işlevsellik için kabul kriterlerinin otomatikleştirilmiş testler olarak yaratıldığı test-ilk yazılım geliştirme uygulaması. Başarısız testler, geliştirme ilerledikçe ve kabul kriterleri karşılandıkça geçecek şekilde yapılandırılır. " - Scrum Geliştirici Sözlüğü (Scrum.org).
Bunlar da beklenen davranışın tanımlarıyla rafine edilebilir :
"BDD (Davranış Odaklı Geliştirme):
TDD'ye yeni işlevselliğin istenen işlevsel davranışının açıklamasını ekleyen çevik yazılım geliştirme uygulaması." - Scrum Geliştirici Sözlüğü (Scrum.org).
Şimdi, woah woah woah orada! Kendimi aşıyorum Kuruluşlar, geliştirme başlamadan önce neredeyse eksiksiz bir Ürün İstek Listesi oluşturmak için çok fazla zaman harcama eğiliminde olabilirler.
Hayır! Ürün İş Listesinin yaşayan bir belge olduğunu unutmayın. Bu ortaya çıkıyor kendisi ürünü olarak ortaya çıkmaktadır . Yapmayın ya tasarım veya geliştirme başlamadan önce büyük bir birikim haline bütün gereksinimlerini belirleme Şelale alışkanlık haline düşer. Ve bir Ürün Sahibi olarak, bir gereksinimi karşılamak için ne yapılması gerektiğine veya bunun nasıl yapılacağına ilişkin ayrıntılarla Ürün İş Listesi maddelerini tek elle iyileştirmeyin ...
Çoğu, Ürün Sahibi'nin aşağıdaki sorumluluğunu yanlış yorumlamaktadır:
"Ürün Sahibi, Ürün İstek Listesini yönetmekten sorumlu tek kişidir." - Scrum Kılavuzu
Geliştirme Ekibi, bir ihtiyacı en iyi nasıl karşılayacaklarını kendi kendilerine belirleyecek şekilde yapılandırılmış ve yetkilendirilmiştir. Bununla birlikte , bunu geliştirme sırasında Ürün Sahibi ile birlikte yaparlar .
"Bu, Ürün Sahibi ve Geliştirme Ekibinin Ürün İş Listesi maddelerinin ayrıntıları üzerinde işbirliği yaptığı sürekli bir süreçtir ." - Scrum Kılavuzu
Geliştirme Takımının yaptığı işin değerini optimize etmek Ürün Sahibi'nin sorumluluğu / hesap verebilirliği olduğundan, onlara ne yapacaklarını ve nasıl yapacaklarını söyleyebilecekleri iddia edilebilir. Ancak Scrum, bunun farklı şekilde yorumlanmasını amaçlamaktadır. Bir Ürün Sahibi bunu en iyi, işlevler arası Geliştirme Takımının yaratıcı ve entelektüel yeteneklerini kullanarak yapar. Ürün Sahibi, ekibin her şeyden önce amacı anlamasına yardımcı olacaktır .
Ne zaman amaç bir PBI açıktır daha fazla ayrıntı eklendikçe, bu arıtma yoluyla ortaya çıkacaktır.
“İyileştirme genellikle Geliştirme Takımının kapasitesinin% 10'undan fazlasını tüketmez. Bununla birlikte, Ürün İş Listesi maddeleri, Ürün Sahibi tarafından veya Ürün Sahibi'nin takdirine bağlı olarak herhangi bir zamanda güncellenebilir. " - Scrum Kılavuzu
' Genellikle ' ifadesinin açıkça belirtildiğine dikkat edin . Ürün İstek Listesini şeffaf bir durumda tutmaya hizmet ederse, biraz daha fazla veya daha az zaman alabilir.
"Hazır" (DoR) tanımları, genellikle varsayılanın aksine, "Bitti" tanımları gibi Scrum Çerçevesi için tam olarak öz değildir. Kılavuz yalnızca şunları belirtir:
"Geliştirme Takımı tarafından bir Sprint içinde" Tamamlanabilen "Ürün İş Listesi öğeleri, bir Sprint Planlamada seçim için" Hazır "olarak kabul edilir." - Scrum Kılavuzu
Genellikle Ürün Sahibi ve Geliştirme Ekibi, bir PBI'nın ne zaman “Hazır” olduğuna dair ortak bir anlayışın Geliştirme Ekibi tarafından tahminine seçilmesine ihtiyaç duyacaktır. Yaygın olarak kullanılan DoR'lerin bir örneği, INVEST kriterleridir . Kılavuzun yalnızca bir tanımı veya gerekliliği vardır ve bu da Geliştirme Takımı'nın tek bir Sprint'te "Bitti" yapılmasının mümkün olduğunu düşünmesidir. DoR'ler uygulandığında, genellikle Ürün Sahibi ve Geliştirme Ekibi imzalamadan önce her bir PBI için yapılması gereken işleri listelerler.
"Hazır" tanımları genellikle iyi bir uygulamadır, ancak reçete edilmemiştir. DoR'ler her şeyin önceden bilindiği ve netleştiği yanılsamasını yaratabilir . Bazen ekiplerin çevikliği ve üretkenliğinin önüne geçebilirlerdi. Bir PBI'nin% 100 net olması gerekmediğini ve Sprint Planlama ve Sprint sırasında Geliştirme Ekibi ve Ürün Sahibinin onlar üzerinde yapılacak iş üzerinde işbirliği yapmaya devam etmesi gerektiğini unutmayın. Geliştirme Ekibi , iş ilerledikçe yeni karmaşıklıklar, daha iyi yaklaşımlar, beklenmedik / tahmin edilemeyen davranışlar ve potansiyel iyileştirmeler keşfedecektir. Ürün Sahibi, potansiyel iyileştirmeleri ve yeni gereksinimleri de keşfedecektir. Bu nedenle DoR'ler işin içindeyken, dikkat dağıtıcı olabileceğinden, bunlar üzerinde sürekli müzakere yapmaktan kaçının . Ekipler, tüm bu değerli içgörüleri 'başlangıçta PBI'da belirtilmediği için' katı bir şekilde görmezden gelme eğiliminde olabilir. DoR'ler gecikme nedeni olabilir ve gecikme maliyetine neden olabilir.
Genelde işbirliği, PBI'lerdeki tüm bu belgelere çok daha iyi bir alternatiftir. PO ve Geliştirme ekibi, kötü yazılmış / okunmuş / yürütülmüş spesifikasyonlara güvenmek yerine, doğrudan işbirliğine güvenmeyi öğrenecek. Zaman zaman belgeye çok daha mantıklı / hangi işin sadece belirtmek edilmiş çalışma yerine, yapılması gereken yapılır.
Kullanıcı hikayelerine güvenmek yerine, sürekli hikaye anlatımına güvenin.
Bir Sprint'te bir PBI üzerinde çalışma "Bitti" olduğunda, bu tüm PBI'nın "Nihai" olduğu anlamına gelmez. Gelişimin artan doğasını kucaklayın. Bir PBI'nın amacına ölçülebilir şekilde tatmin olacak şekilde ulaşması için birkaç yineleme gerekebilir . Kullanım sırasında, bir PBI üzerinde yapılan iş sürekli denetime ve adaptasyona tabidir. Daha fazla şey öğrenildikçe, aşamalı olarak üzerinde çalışmalar yapılmaya devam ediyor.
Scrum, siparişi Ürün Sahibi'nin takdirine bıraksa da, en üstteki öğelerin daha ayrıntılı ve daha değerli olduğunu ima eder. Her türlü uygulama yapılabilir.
Önceliklendirmeye alternatif sıralama kullandığımızı unutmayın . Kılavuzda yapılan ilginç bir güncelleme, esas olarak önceliğin üzerinde çalışılacak öğelerin sırasına eşit olmadığı fikri etrafında dönüyor . Genelde en iyi sonucu verecek yukarıdan aşağı sıralı bir liste buluyorum, ancak bu benim kişisel bir tercihim. Bu, neye odaklanılacağını anında netleştirir ve MoSCoW'un yaptığı gibi prio'nun belirsiz yorumlanmasına yer bırakmaz. Moskova ile, o genellikle benim deneyim misiniz Olması gerekenler genellikle eşittir asla Haves ve herkes bunu biliyor. Tonlarca Zorunluluk olacak . Bu, Geliştirme Takımının odaklanabilmesi için ihtiyaç duyduğu şeffaflığı yaratmaz . Ekibin bu Zorunluluklardan hangisine odaklanacağını sorduğumda , cevap genellikle 'hepsi' oluyor. Öğeleri Zorunluluklar olarak işaretlemek , sabırsız paydaşları öncelikli görüneceklerinden uzak tutmak için kullanılabilecek bir teknik olsa da. Gerçek şu ki, bu şekilde hiçbiri etkin değil.
Scrum.org bize olası bir Ürün İş Listesinin bu görsel temsilini verir:
Bir Ürün İş Listesi , takımın geçmiş performansına ve bugüne kadar kaydedilen ilerleme oranına dayandığı ve yalnızca İş Listesi şu anda olduğu sürece, projeksiyonları da içerebilir / içerebilir . İş yığını zamanla değiştikçe bunlar da değişecektir. Ancak sorun, beklentiler belirlendiğinde paydaşların bunların karşılanmasını bekleyecek olmasıdır. Bu olacak zehirli uygulamalara yol olacak onlar gibi Scrum Takımı daha sert hale olacaktır yeni değerli keşifler adapte üzerinde bu beklentileri karşılamak için cazip.
Bir Ürün Sahibi, genellikle Sprint İncelemesi sırasında bu tahminleri paydaşlar için şeffaf hale getirir:
"Ürün Sahibi, Ürün İş Listesini olduğu haliyle tartışır. Şimdiye kadarki ilerlemeye dayalı olarak muhtemel hedef ve teslimat tarihlerini tahmin ediyor (gerekirse); " - Scrum Kılavuzu
Scrum.org bize şu görsel örneği veriyor:
Ürün Sahipleri de Çevik Ürün Portföy Yönetimi (PPM) gibi Ürün İş Listesini sipariş ederken hiyerarşik bir yaklaşım benimseyebilirler.
Ürün İstek Listesi'nin sırası da PBI'lar arasındaki olası bağımlılıkları ortaya çıkarabilir. Birlikte gruplanabilirler, renklendirilebilirler veya bağlantılı olabilirler ve ne olmayabilirler. Bunları sadece örnek olarak paylaşıyorum ve bunun yalnızca Ürün Sahibine bağlı olduğunu ve konudaki seçimlerine her zaman saygı duyulması gerektiğini bir kez daha vurgulamak istiyorum. Scrum Master, Ürün Sahibine olası “etkili Ürün İş Listesi yönetimi için teknikler” paylaşarak ve “Scrum Takımının net ve öz Ürün İş Listesi öğelerine olan ihtiyacı anlamasına yardımcı olarak” yardımcı olacaktır. Ürün İş Listesi sıralamasının iyileştirilmesi, herhangi bir Retrospektif için de hoş bir konu olabilir!
" Hayır " adlı bir olası tekniği daha paylaşmayı umursuyorum . Bu gitmeli ne olmamalı içine Ürün Gereksinim ama ne olmamalı (ya da ne kaldırılmalıdır) . Unutmayın ki, bir " hayır " cevabını verirken , bunu paydaşlarla ilişkiyi yönetirken " evet " e dönüştürmek için neye ihtiyaç duyulacağını açıklamaya özen gösterin.
"Basitlik - yapılmayan iş miktarını maksimize etme sanatı - çok önemlidir." - Çevik Manifesto
Oh oğlum. Bu iki konuyu ele almaktan heyecan duyuyorum, ancak aynı zamanda alıştırmadan da korkuyorum. Scrum Kılavuzunun bu konuda söyleyecek çok az şeyi olmasına rağmen ele alınacak çok şey var. [Bunu bir sonraki bölümde ele aldım .]
Ürün İş Listesi maddeleri, gerçek ürünün kullanımına ilişkin incelemeleri ve ölçütleri içerebilir / içermelidir. Sadece dolu edilmemelidir assumed ihtiyaçlarına tahmin değeri. Çoğu ekip, sürekli bir dağıtım ve unut üretim modundadır. Her zaman yeni şeyler üretiyorlar. Ölçümler ve denetimler işin içinde olduğunda bile, oyunu neredeyse hiç etkilemezler. Geliştirme kuruluşları, beklenen değerin gerçek değere dönüşüp dönüşmediğini hemen hemen hiç onaylamaz . Teftiş, Scrum için temeldir ve etkisi, Ürün İş Listesinin düzenlenme biçiminde yansıtılmalıdır.
O, benim de deneyimlediğim gibi, birikimin doğrudan işbirliği yapmak zorunda kalmamak için bir bahane haline geldiğini gösteriyor. O da benim gibi birikmiş ihtiyaçlar belgesinden korkuyor. Ron, Scrum'ın düzgün bir şekilde uygulanmadığı durumlarda (ki bununla yüzleşelim, büyük şok edici çoğunluktur) bir Ürün İş Listesi'nin ters etki yaratabileceğine dikkat çekiyor.
Ron, bir dereceye kadar kabul ettiğim bir hata , Scrum Kılavuzunun İş Listesi'nin "tüm" gereksinimleri içermesi , böylece buna tüm savurgan mumbo jumbo'ları da dahil etmesidir.
Pek çok uygulayıcı, İş Listesini bir Gereksinim Belgesi olarak ele alma geleneksel davranışını genellikle varsayılan olarak kullanır. Ürün İş Listesini, her türlü bürokratik öznitelik ve girdi gereksinimleri içeren, çok sayıda dış kaynağa bağlanan, kötü yazılmış özellikler ve önyargılı varsayımlar içeren, neredeyse hiç erişilemeyen, fazla yapılandırılmış bir Jira veya elektronik tablo ortamında saklanmış buluyorum.
Karanlık uygulamalar şöyle devam ediyor:
Yukarıdakileri belirttikten sonra, Ürün İstek Listesinin son derece değerli olduğuna hala inanıyorum. Oyunda olmalı ve takımlar bu konuda ustalaşmayı öğrenmelidir. Burada ' Ri ' seviyesi içgörülerinden bahsediyorum .
Ben şahsen, Scrum Takımlarının olgun Scrum ortamlarında, benimsediği tüm değerler ve ilkelerle birlikte ... çok hafif bir versiyonundan çalışabileceğine inanıyorum . Bu, yalnızca gerçek çalışma alanında bir pano üzerinde görselleştirilen en yakın değerli öğeleri içerebilir. Bu, son sorumlu anda gerekli olan belgeleri içerebilir.
Bu konuda ele alınacak daha çok şey var. Bu bölümün Ürün İstek Listesini tatmin edici bir düzeyde kapsadığını hiçbir şekilde düşünmüyorum. Çok sayıda şaşırtıcı uygulama, anti-kalıplar ve örneklerden bahsedilebilir. Sizi en sevdiğim referanslardan birine yönlendireceğim: Hizmet Tasarım Araçları . Bu site, Scrum Takımlarının ürünü, pazarı, müşterileri, kullanıcıları ve birbirlerini daha iyi anlamalarına yardımcı olmak için katılabilecekleri birçok yararlı atölye içerir.
PSM III'e Giden Yol, Ustalığa Giden Yol olarak yeniden biçimlendiriliyor !
Bölüm I: Down the Rabbit Hole artık mevcut.
PG Inbox'a hoş geldiniz! Her hafta, dünya genelinde ürün ve büyüme alanında dünyanın en iyi yazarları tarafından son 7 gün içinde yayınlanan 1000'den fazla makaleyi inceliyoruz. Ardından, topluluğumuzun en çok keyif alacağını düşündüğümüz makaleleri derliyoruz.
Birkaç yıl önce bir Yazılım Mühendisliği konferansına katıldım ve bir konuşmacı kalabalığa Yazılım Mimarlarının geliştirdikleri yazılıma varsayılan olarak hangi özellikleri yerleştirmeyi düşünmeleri gerektiğini sordu. Birçoğumuz ne kadar akıllı olduğumuzu göstermeye çalışarak ellerimizi kaldırmaya başladık.
Modern veri bulutunun içinde ve sırada ne var? Veri adası sorunları ve ilk 8 trend Prelude Data Cloud uçsuz bucaksız bir alemdir.
Empati, bir başkasının durumu, zihni (düşünceleri) ve hissi (duyguları) hakkında farkındalık eylemi/sürecidir. Başkalarının bakış açısını anlama kapasitesidir.
Bir keresinde kocam çöplerimizi karmaşık çöp bidonumuza götürürken, dost canlısı, kayıp bir kedi yavrusuyla karşılaştı. Onu eve götürmeye ve ardından sahibini bulmaya karar verdi - ta ki kadın miyavlayana kadar.
Yapay Zekaya Giriş Yapay Zeka (AI), endüstrilerde devrim yaratma, yaşama ve çalışma şeklimizi değiştirme ve topluma sayısız fayda sağlama potansiyeline sahip, hızla gelişen bir teknolojidir. Ancak, her yeni teknolojide olduğu gibi, dikkate alınması gereken etik hususlar da vardır.