Bir Scrum ekibi planlama toplantısındaki altyapı görevlerini nasıl hesaplar?

Bir Scrum ekibi planlama toplantısındaki geliştirme / altyapı görevlerini nasıl hesaplar?

İlk bakışta, son kullanıcı değeri sunmadıkları için kullanıcı hikayeleri gibi gözükmüyorlar.

Ancak, bunları belirli bir kullanıcı hikayesine görev olarak eklemek bazen bir anlam ifade etmiyor. Örneğin, görevin: "Bambu Kurulumu" olduğunu söyleyin. Bu görevin, herhangi bir kullanıcı hikayesini tamamlaması gerekmez, çünkü ekip el ile oluşturabilir ve dağıtabilir. Bu nedenle, bir kullanıcı hikayesine eklemek, bu görevi kullanıcı hikayesini tamamlamak için gerekli olmadığından bir anlam ifade etmiyor.

Öyleyse, bu, bu görevlerin kullanıcı hikayeleri haline geldiğini gösteriyor. Ancak, eğer ekip hikayesi onları işaret ederse, bu, Ürün Sahibinin, bir dizi teknik kullanıcı hikayesi eklenmiş olan birikimine karşı değil, biriktirme sırasına karşı olan hızı bilmek istediğinden beri tuhaf olan hızı değiştirir.

Aslında kullanıcı hikayeleri değiller. Onlar paydaş hikayeleri. Yazılım aslında kullanıcılar tarafından doğrudan ödenmediği sürece, tamamen kendi yararına bir hikaye oluşturulması nadirdir.

Size birkaç örnek vereceğim:

• reklamverenlerin daha etkili reklamlara sahip olmalarını sağlayan anahtar kelimeli makaleler
• Moderatörlerin spam ile manuel olarak uğraşmalarını durdurmak için orada bulunan CAPTCHA'lar.

Teknik hikayelerin çoğu aslında bir ticari fayda sağlar, ancak bu kullanıcılar için nadiren olur. Onları farklı bir şekilde ifade etmek yardımcı olabilir. Normalde Chris Matts 'Özellik Enjeksiyon şablonunu kullanıyorum:

In order to <achieve my goal>
As <the stakeholder who wants the goal>
I want (<some users to do>) <some stuff>.

Bu, geliştirme ekibi de dahil tüm paydaşları açıkça tanır. Artık teknik hikayelerinizi de ifade ederek, işletme avantajını dile getirebilirsiniz:

In order to minimize the risk of deploying something broken
As the team deploying the code
We want to spend a few days on an automated deployment system.

Bununla ilgili birkaç blog yazısı yazdım: Bunlar Kullanıcı Öyküleri değil , Özellik Enjeksiyonu ve teknik öykülerle ilgilenmek . Umarım yardım ederler.

Hız, ekibin faydalı işler yapma kapasitesinin bir ölçüsüdür (Drag yerine). Altyapı görevleri, ekibin uzun vadede daha verimli olmasını sağlayarak, dolaylı olsa da, son kullanıcı değeri sunmaya devam ediyor. Bunları kullanıcı hikayeleri olarak izleme konusunda bir sorunum yok (kullanıcı bu durumda geliştirici olan ekiptir) ve bunları öncelik sırasına koymak. Müşteri (ler) ile iyi iletişim halinde olan bir Ürün Sahibi, bu tür görevlerin teslimatları bozmadan nereye uyabileceğini çözebilmelidir.

Onları yavaş yavaş yapın.

Hiçbir paydaş bunu istemiyorsa, bir hikaye yapmayın. Sadece bir anda biraz ilgilen. Örneğin, ilk defa manuel olarak dağıtıyorsunuz. İkinci kez, biraz otomatikleştiriyorsun. Üçüncü kez, biraz daha otomatikleştiriyorsunuz. Sonunda yapınız en büyük sorun değil, bu yüzden başka bir şeye odaklanıyorsunuz.

Bu geliştirici odaklı görevlerin çoğuna daha önce sahip olacaksınız ve sorun değil; Hızınız (hikayelerle ölçüldüğü gibi) sadece daha düşük olacaktır. Bu durumun doğru bir temsilidir. Ancak her zaman biraz olacak, bu yüzden ekibin süreci iyileştirmek için gerekli olanı yapma alışkanlığı kazanması önemlidir.

IMHO, ideal yaklaşım, ilk değeri taşıyan kullanıcı hikayesi altındaki görevler olarak altyapı çabasını koymak; Bahsettiğiniz gibi.

Örnek alarak; elle inşa etmek ve dağıtmak, devam eden bir çaba olduğunu ve tamamlanma biçiminin olmadığı anlamına gelir. Süresiz var.

Aynı şey daha önce manuel olarak yapılan tipik bir uygulamada eforun herhangi bir bölümünü otomatikleştiren kod için söylenebilir. Bu çabayı bir kullanıcı hikayesi altında bir görev olarak tanımlamak, tamamlamayı; doğası gereği son kullanıcı için değere sahiptir.

Uygulamayı her bir sprint kesinlikle oluşturabilir ve dağıtabilirsiniz, ancak bu, günlük olarak, iş listesiyle resmen takip edilmeyen günlük işlerin bir parçası haline gelir ve sonra hepsi tartışılır hale gelir.

Kullanıcı hikayeleri, bir işletme değerini kullanıcı perspektifinden tanımlar. Bu nedenle altyapı işleri genellikle "atık" olarak kabul edilir. İhtiyaç duymadıkları anlamına gelmez. Daha fazla altyapı görevi yapmanın daha az iş değeri sağlayacağı anlamına gelir. Bu nedenle, altyapı işleri bir kullanıcı hikayesi olarak görülmemeli ve herhangi bir kullanıcı hikayesine eklenmemelidir.

Bir planlama toplantısında bir sonraki sprint boyunca hangi altyapı görevlerinin kesinlikle gerekli olacağını düşünmelidir. Taahhüt, bu altyapı işleri göz önünde bulundurularak gerçekleştirilecektir. Takımın hızını etkileyecektir, çünkü sonuç takımın ne kadar işletme değeri sunabileceğini ölçmektedir.

Kullanıcı hikayelerini asla son kullanıcı değeri sunma ile eşitlemedim. Yaygın olabilir, ancak kullanıcı hikayeleriyle nasıl başa çıkacağımızı değil. Bazen bu tür görevler sivri sayılır, ancak diğer kullanıcı öyküleri gibi tahmin edilen düzenli kullanıcı öykülerimiz de vardır.

Gördüğüm kadarıyla altyapının büyük bir kısmı kabul edildi. Bu gibi şeyler içerir:

• Revizyon kontrol sistemi;
• Otomatik yapı sistemi;
• IDE ve diğer geliştirici araçları;
• Geliştirme sunucuları;
• Dağıtım işlemi; ve
• Proje süreci ve standartları.

Çalıştığım metodolojilerin çoğu onlara çok fazla önem vermiyor. Bu, benim Sürüm 0 olarak adlandırdığım formu oluşturur. Bunlar gelişmeye başlamadan önce yerinde olmalıdır. Hikayeler üzerinde çalışmaya başladığınızda, bu şeylerdeki herhangi bir değişiklik süreç iyileştirme olarak izlenebilir.

Geliştirme ekibi girdi almış olsa da, bu öğelerin çoğu bir proje destek ekibi tarafından ele alınmalıdır. Bu kalemlerin birden fazla projede standartlaştırılması, organizasyon için önemli bir geri ödeme almalıdır.

Aşağıdakileri göz önünde bulundur:

• Scrum ekibi mevcut bir ürün grubuna ana özellikler ekliyor.

• En iyi mühendislik uygulamalarına dayalı olarak güncel kalmak için geliştirme teknolojisini / araçlarını / yardımcı programlarını yükseltme ihtiyacı vardır.

• Bu çalışma ile bir yayını önden yüklemenin anlamı vardır, böylece yayın sırasında Sprints sorunları çözülebilir.

• İş bu ürünlerden dolaylı bir değer elde ettiğinden, şeffaflık için bunların Ürün İhtiyaçları Listesi (PBI'ler) olduğunu düşünüyorum.

• Ekip bu maddeleri boyutlandırıyor ve onlara herhangi bir PBI gibi davranıyor.

Benim için bu mesele, bu işi diğer iş merkezli PBI'lerin altındaki görevler olarak nasıl gizleyeceğimizi bulmak için zaman kaybetmek istemememden kaynaklanıyor.

PBI boyutlandırmasının bu tür bir altyapı çalışmasında çarpıtılmasını istemiyorum. Ne yapıldığını görmek ve ne için para ödediğimi anlamak istiyorum.

Ayrıca, ekibin, kaliteli çözümler sunmak için gereken altyapıya yatırım yaparak şirketin yaptığı taahhüdü anlamada değer olduğunu düşünüyorum.

XP önerir , tüm araçların ve altyapının kurulduğu "sıfırlama" önerir. Bunlar için hikayeler yazmak isteğe bağlıdır, ancak muhtemelen iyi bir fikirdir. Altyapınızı test edebilmek (artan yapı, otomatik test ve dağıtım, bildirimler vb.) Faydalıdır.

Ekibimizde aşağıdakileri yapıyoruz:

1. Farz et düşük bir odaklanma faktörü .
2. Bu tür görevleri kullanıcı hikayelerine dahil etmeye çalışın , gerçekte bunları uygulaması gereken .
3. Bazı görevler tamamen gerekliyse ancak doğrudan iş değeri sağlamazsa (ünite testlerini bir çerçeveden diğerine geçirmek gibi), sprint başlangıcında "sürekli görevler" in bir listesini oluştururuz . Bunlar, hikaye olmayan gelişim ile ilgili görevlerdir, ancak geliştirme ekibi bunların yapılmasını ister. Bu işleri yazı tahtamızda sıralıyoruz, yine de hikayelerden ayrı tutuyoruz. Sprint sırasında, her günlük toplantıda bunları başarmak için neler yapıldığını gözden geçiririz.

2. adım en önemlisidir. Çevik bir pratikte olduğu gibi, Scrum'da görevlerinizi başarmak için mümkün olduğunca az şey yapmaya çalışıyorsunuz. Gereksiz işler yaparak hayatınızı boşa harcamamanın bir yolu olarak kabul edin: Tecrübelerime göre, "harika olurdu" olaylarının% 50'sinin uzun vadede terk edildiğini ve kullanılmadığını gösteriyor.