Ürün İş Listesi Öğesi ile Görev arasındaki farkı açıklama


22

Bu zorluğa birkaç kez rastladım ve birinin bir Ürün İş Listesi ile TFS'deki Görev arasındaki farkın nasıl açıklanacağına dair bazı referanslar, eğitim veya tavsiyeler sağlayabileceğini umuyorum.

Bir Ürün İş Listesinin “Ne” olduğunu ve Görev'in “Nasıl” olduğunu anladım ve açıkladım. PBI'nın gereklilik olduğunu ve Görev gerekliliğin nasıl karşılandığını da açıkladım.

Bunu açıklarken defalarca boş bakışlarla ve kafa çizilmeyle karşılaşıyorum. Anladığım kadarıyla bunu açıkladığım Yazılım Mühendisleri arasında ayrım yapamıyorum. Hepsi onlar için aynı.

Diğer zorluğumun, ayrım yapmanın neden önemli olduğunu etkin bir şekilde açıklayamadığımı düşünüyorum.

Yanıtlar:


27

"Ürün biriktirme öğesi" aslında inşa edilmesi gereken işlevselliktir. Görev, oraya ulaşmak için atılması gereken adımları açıklar.

Birçok ekip görevlere ayrışmak için kullanılmaz, sadece teknik özelliklerin söylediklerini oluştururlar. Bu insanlar için onları iki ayrı şey olarak görmek zor.

Belki basit bir fıkra yardımcı olur:

Tatil için Ürün Listesindeki Öğe'leri alışveriş listesindeki öğeler olarak görün. Belki bir "çadır", "olta", "seyahat için araba hazırla".

"Çadır" öğesinin Görevleri "Çadır gereksinimlerini tanımla", "Çadırları çevrimiçi karşılaştır", "Açık hava deneyimine sahip arkadaşlardan tavsiye al", "Açık hava dükkanına git", "çadır satın al", "arka bahçeye çadır kur" "," seyahat için paket çadır "ın eksiksiz olduğunu doğrulayın

Olta için Görevler çok benzer olacaktır, ancak "seyahat için araba hazırla" görevleri muhtemelen çok farklıdır: "İstenen rotadaki eyaletler / ülkeler için gereklilikleri kontrol et", "güvenlik yeleği al", "süresi dolan içerikleri ilk yardımdan değiştir kit "," yedek lastiği kontrol et "," motorun kontrol edilmesi için garajla randevu planla "," motorun kontrol edilmesi için garaja git "," otoyol geçişi almak için devlet acentesine git "," araba sigortasını kontrol et "

Bu, ürün sahibinin ne istediği sorusunu yapması gerekenden açıkça ayırır. Elbette, ürün sahibi zaten Ürün İhtiyaçları Belgesi'nde eyleme dönüştürülebilir maddelere ayrıştırılmamışsa, bu durumda onlarla konuşmanız gerekir.

Dediğim gibi, birçok geliştirici için zaten yeterli bilgiye sahip olduklarını ve ne yapacaklarını bildiklerini sanıyorlar, Neyin Nasıl Olduğunu adımlarını ayırmak istemiyorlar, oraya vardıklarında oraya varacaklar. Sprint ilerlemesini izleme, tahminleri iyileştirme, sprint planlaması sırasında unutulmuş çalışmaları izleme ve profesyonel iyileştirmelerle ilgisi olan diğer öğeler hakkında onlarla konuşmaya başladığınızda, onlara ve ekibinin nerede ve nasıl geliştirebileceklerini nasıl bileceklerini sorun Gerçekten yaptıklarını biliyorum. Görev oluşturmadan çalışan ve işe yarayan bir sistemle karşılaştıklarında ve işe yarıyorsa, o zaman sorun değil, ancak şanslar gerçekten yapabilecekleri kadar düşük.

TFS ve çevik araçlarla çalışmayı denemeden önce ekibinizin tüm işlemlerin nasıl yürüdüğünü anlaması gerekecektir. En iyi yol, çalışma alanında herkes tarafından görülebilen bir kağıt tahtası ile çalışmalarını sağlamaktır. Daha sonra, süreç daha iyi anlaşıldığında, aletlere hareket etmek yardımcı olacaktır. Anlayış olmadan, araçlar çok fazla kullanılmayacak ve çok fazla dirençle karşılaşacak.


Bu cevabı yazmak için zaman ayırdığınız için teşekkür ederiz. Sağladığınız fıkra ve akıl yürütme kavramı kesinlikle daha iyi açıklamama yardımcı olacaktır.
Brad J

@jessehouwing Proje sahibi açıkça “araba sigortasını kontrol etmek” isterse. BacklogItem veya Görev nedir?
Vladimir Nani

Operasyonel bir şey gibi geliyor. Bu yüzden bir görev olurdu. Ama nasıl değer veriyor? "Araba her zaman sağlandığından emin olun", Öykü olabilir mi?
jessehouwing

8

Bence Jesse harika bir cevap verdi. Ben basitçe denemek ve daha iyi hale getirmek için gidiyorum (mümkünse) :) Ürün İş Listesi (veya eğer isterseniz Kullanıcı Hikayesi) genellikle şöyle yazılır:

Yeni Bir Müşteri Olarak Yeni Ürün Yayını hakkında bilgi sahibi olmak için bilgilerimi kaydetmek istiyorum

Bir geliştirici kafasında bu, aşağıdakilere çevrilebilir:

  1. Kayıt formu oluştur
  2. Kayıt verilerini veritabanına yaz
  3. Kayıtlarını onaylamak için yeni müşteriye e-posta gönder

Bu üç öğe görevlerdir.

Umarım yardımcı olur.

- Mümkün olduğu kadar basit ama basitleştirmeyin (Einstein)


2

İşte yuvarlanma şeklimiz:

PBI:

  • olan gereksinimi aka "ne"
  • Bir müşteriyle konuştuğun şey bu .
  • Bu sprint için Günlük Proje Güncellemesinde (DPU) ortaya çıkan şey… yine de çünkü DPU müşterinin karşısına çıkıyor.
  • Müşterinin konuşacağı ve tahminler ve bütçe açısından bakacağı şey budur.
  • Bir veya daha fazla görev içerebilir.
  • İş odaklı ve müşterinin anladığı iş odaklı / etki alanı tarzı bir dilde tanımlanır.
  • Kullanıcı Kabul Testinde (UAT) test edilen ve kabul edilen şey

Görev:

  • PBI'yi gerçekleştirmek için gerekli bir çalışma mıdır (gereklilik)
  • Bir müşteriyle bahsettiğin bir şey değil
  • DPU'da görünmüyor çünkü müşterilerle onlar hakkında konuşmuyorsunuz
  • Tahmin edildi, ancak tahminleri PBI’ye yuvarlandı mı?
  • Çocuk bir ve sadece bir gereksinimdir.
  • Teknik jargon kullanılarak tanımlanabilir (ve sıklıkla da olabilir).
  • Dahili olarak test edildi ve testle imzalandı
  • Müşteri tarafından ayrı ayrı kabul edilmemiş veya test edilmemiş (var olduklarını bilmiyorlar)

-4

Sorulduğunda bunu teklif etme eğilimindeyim: -

Bir PBI veya Öykü, birden fazla insanın yaşayabileceği bir şeydir.

Görevler, yalnızca bir kişinin alabileceği bir şeydir.


1
Bu açıklamanın tam resmi sağladığını sanmıyorum, ancak konuşmaya odaklanmaya yardımcı olabileceğini görebiliyorum.
Brad J
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.