“İlişkili” çalışmayı tek bir çevik iş öğesinde ele alma

Ben de dahil 4 devs proje ekibindeyim. Tek bir iş kaleminde ortaya çıkan ekstra işi nasıl ele alacağımız hakkında uzun bir tartışma yaşıyoruz.

Bu ekstra çalışma genellikle görevle biraz ilgili olan, ancak öğenin amacına ulaşmak için her zaman gerekli olmayan şeylerdir (bu bir fikir olabilir). Örnekler aşağıdakileri içerir ancak bunlarla sınırlı değildir:

• iş öğesi tarafından değiştirilen kodun yeniden düzenlenmesi
• öğenin değiştirdiği koda komşu yeniden düzenleme kodu
• biletin etrafındaki daha geniş kod alanını yeniden tasarlamak. Örneğin, bir öğe tek bir işlevi değiştirirse, bu değişikliğe daha iyi uyum sağlamak için tüm sınıfın artık yeniden yapılabileceğini fark edersiniz.
• yeni değiştirdiğiniz bir formdaki kullanıcı arayüzünü iyileştirme

Bu ekstra iş küçük olduğunda aldırmıyoruz. Sorun, bu ekstra çalışmanın, öğenin orijinal özellik noktası tahmininin ötesinde önemli ölçüde genişlemesine neden olmasıdır. Bazen 5 puanlık bir öğe aslında 13 puan alır. Bir durumda, geriye dönük olarak 80 puan veya daha fazla olabilecek 13 puanlık bir öğemiz vardı.

Tartışmamızda bunun nasıl ele alınacağına dair iki seçenek var.

1. Aynı iş öğesindeki ekstra işi kabul edebilir ve yanlış tahmin olarak yazabiliriz. Buna ilişkin argümanlar şunları içeriyor:

   • Bu tür bir şeyi hesaba katmak için sprint sonunda "dolgu" yapmayı planlıyoruz.
   • Kodu her zaman bulduğunuzdan daha iyi durumda bırakın. Yarım yamalak işi kontrol etmeyin.
   • Daha sonra yeniden düzenleme yapmayı bırakırsak, programlamak zordur ve asla yapılamayabilir.
   • Zaten kodun derinliklerinde olduğunuz için, bu işi şimdi ele almak için en iyi zihinsel "bağlamda "sınız. Şimdi yoldan çekilmek ve daha sonra geri döndüğünüzde bu bağlamı kaybetmekten daha verimli olmak daha iyidir.

2. Mevcut iş kalemi için bir çizgi çiziyoruz ve ekstra işin ayrı bir bilete gittiğini söylüyoruz. Bağımsız değişkenler şunları içerir:

   • Ayrı bir bilete sahip olmak yeni bir tahmine izin verir, bu yüzden şeylerin gerçekte kaç puan olduğu konusunda kendimize yalan söylemiyoruz veya tüm tahminlerimizin korkunç olduğunu kabul etmek zorunda değiliz.
   • Sprint "dolgusu", bilet gereksinimlerini karşılamanın doğrudan engelleri olan beklenmedik teknik zorluklar içindir. Sadece "iyi niyetli" yan öğeler için tasarlanmamıştır.
   • Yeniden düzenleme planlamak istiyorsanız, iş yığınının üst kısmına koymanız yeterlidir.
   • Bu tür şeyleri bir tahminde doğru bir şekilde açıklamamızın bir yolu yoktur, çünkü ortaya çıktığında biraz keyfi görünmektedir. Bir kod inceleyici "bu UI denetimleri (aslında bu iş öğesinde değiştirmediğiniz) biraz kafa karıştırıcı olabilir, bunu da düzeltebilir misiniz?" Bu bir saat gibidir, ancak "Bu kontrol şimdi diğerleriyle aynı temel sınıftan miras alıyorsa, neden tüm bu (yüzlerce satır) kodu tabana taşımıyorsunuz ve tüm bunları yeniden sarmıyorsunuz? , basamaklı değişiklikler vb.? " Ve bu bir hafta sürüyor.
   • Bilete ilgisiz çalışmalar ekleyerek "suç mahallini kirletir" ve orijinal özellik nokta tahminlerimizi anlamsız hale getirir.
   • Bazı durumlarda, ekstra çalışma bir check-in işlemini erteleyerek geliştiriciler arasında engellemeye neden olur.

Bazılarımız şimdi bazı kesintilere karar vermemiz gerektiğini söylüyoruz, ek şeyler 2 FP'den azsa, aynı bilete gidiyor, eğer daha fazla ise, yeni bir bilet yapın.

Agile'ı kullanmaya sadece birkaç ay kaldığımız için, buradaki daha deneyimli Agile gazilerinin bunun nasıl ele alınacağına dair görüşü nedir?

Çevik planlama ve kullanıcı hikayeleri, proje paydaşlarına ve yazılım kullanıcılarına değer ve şeffaflık sağlamaya odaklanmıştır. Bu iyi bir şeydir, ancak iyi mimari yönergelerin, tasarım yönetiminin, iyi geliştirme uygulamalarının ve teknik borcun korunmasının önemini ortadan kaldırmaz, içermez veya içermemelidir.

Agile ikincisini iyi yapmaz, çünkü çoğunlukla teknik sorunlara ve sorunlara bir cevap olarak tasarlanmamıştır.

Yeniden düzenleme görevlerinin, teknik borç yönetiminin ve tasarım çalışmalarının belirli bir sprint'te ayrı kullanıcı hikayelerini açıklaması gerektiğini kesinlikle kabul etmiyorum. Bunlar sadece bir geliştiricinin o sprint için kullanıcı hikayesini karşılamaya yardımcı olmak için üstlenebileceği görevlerdir.

Bir Görevin, belirli bir kullanıcı hikayesini mimari yönergeler içinde tamamlamaya ve yazılımın bir bütün olarak iyi tasarım ve geliştirme uygulamalarını sürdürmeye yardımcı olan herhangi bir atanabilir çalışma birimi olduğunu unutmayın .

Bu nedenle saat tahmini kullanıcı öykülerinde değil görevlerde olmalıdır. Bazı görevlerin birden çok kullanıcı hikayesinin tamamlanması için kritik olmasının nedeni de budur.

Kırmızı, Yeşil, Refactor. Bu, tek bir iş öğesinin kapsamıdır. Değişiklik kapsamını kapsayan başarısız bir test paketi yazın, testinizi geçmek için gereken minimum miktarı kodlayın, daha sonra testleri geçerken kodlama standartlarını karşılayacak şekilde yeniden düzenleyin. Bu adımların üçü de gereklidir; Sorunu tanımlayana kadar çözümü kodlayamazsınız, kod satırını yazarken yeniden düzenleme yaparsanız, YAGNI'yi her zaman ihlal edersiniz, ancak testleri geçtikten sonra kendinize gelmezseniz ve refactor, tanım gereği teknik borca ​​girersiniz sonunda geri ödemeniz gerekecek.

Bu tanım ve takip edildiğinde, 13-işaretçi olduğu ortaya çıkan 5-işaretçi yanlış bir tahmindi. İşi yeniden düzenlemeyi düşündüğünüz şey muhtemelen yeniden yapılanmaya benziyordu; yeni işlevselliğin anlaşılabilir ve sürdürülebilir bir şekilde dahil edilebilmesi için kod tabanının oldukça önemli bir alanını yeniden düzenlemeniz gerekiyordu. Bu, genellikle takımın gelecekteki genel gelişim yolunu anlamada başarısız olduğunu gösterir ve bir şeyin daha sonra SOLID olması gerektiğinde önceki bir yinelemede çok basit bir şekilde uygulanmasına yol açar. İş birikiminde nelerin daha aşağı olduğunu bilen BA'lar ve PM ile daha iyi iletişim kurmak ve genellikle mevcut sprint'e odaklanan geliştirme ekibi bunu hafifletebilir. Alternatif olarak, bu hikaye geçmişte ortaya çıkan büyük miktarda teknik borcu ortaya çıkardı, ve sadece takıma yetişti. Tasarım kalıpları ve projenin gelecekteki genel yolu hakkında daha iyi kavramsal bilgiye ek olarak, daha iyi kod inceleme süreçleri, bu tür olayların azaltılmasına yardımcı olabilir.

Akılda tutulması gereken bir şey, yeniden düzenlemenin "ideal olmayan" bir çalışma olduğudur. Agile SCRUM'da görevler "ideal saatler" olarak tahmin edilir; yani, hiç var olmayan yepyeni bir kod yazmak ve projenin özellik tabanını ilerletmek için harcanan saat sayısı. 8 saatlik bir geliştirici günü gerçekçi olarak yalnızca 5 ideal saate sahip olabilir; bazen 6'ya güvenebilirsiniz, özellikle de ekibin gerçekten mırıldanmakta olduğu bir projenin "gerilmesi". Projenin işlevselliğini etkilemeyen, ancak kod tabanını başka şekillerde iyileştiren yeniden düzenleme veya geri dönme ve değişiklikler yapmak, planlama, tasarım, iletişim, inceleme, aralar veya teknik kesintiler gibi ideal olmayan bir iştir. Teknik kesinti süreleri dışında ideal olmayan çalışmalar önemlidir, ancak ürün sahibinin gözünde ilerleme kaydetmez.

Dolayısıyla, yeniden düzenleme işleminin harcanan gerçek saati iki katına çıkarmaması koşuluyla, ideal saatleri tahmin ettiğinizde belirli miktarda yeniden düzenleme çalışması beklenir. Diyelim ki, takımınızın puan ölçeğinin tam olarak nasıl kalibre edildiğini bilmiyorum, 5 işaretçi bir ideal geliştirici haftası veya yaklaşık 25 ideal saate eşdeğer. 13'e (aynı ölçekte iki haftadan fazla geliştirici haftası) dönüşen bu 5, karmaşıklığın balonlaşmasına neyin neden olduğu hakkında bazı retrospeksiyonlara neden oluyor. Belki de kod tabanının gerçekte olduğu kadar yeniden düzenlemeye ihtiyacı yoktu, belki de yeni özelliklerin çalışması için çözülmesi gereken ekibe göre büyük miktarda teknik borç birikmişti,

Alternatif bir evrende, ideal saatlerde tahmin edildiği gibi 5'in gerçek saatlere göre 7 (~ 35 saat) haline geldiğini düşünelim, çünkü yeni kodu ve önceki bazı bitleri düzgün bir şekle sokmak için 10 saat ek yeniden düzenleme gerekiyordu tasarım mimarisi. Bu durumda, ekstra, hikayenin alması gereken geliştirici-gün sayısı boyunca ideal ve toplam saatler arasındaki "boşluk" içindedir. Yani, proje yöneticisi olarak, 7 olan makul bir tahmin ve devam eden 5'i çağırırdım.

Öykü noktaları, belirli bir kullanıcı öyküsünün göreli karmaşıklığının bir tahminidir. Görünüşe göre bu, X adamının gün / saat alacağını söylemek için hikaye noktaları kullanıyor. Bunun yerine, iki hedef için çabalayın

1. Hikayeleri tutarlı bir aralıkta olana kadar yıkın (3, 5 veya 8 puan)
2. Öykünün gerekli yeniden düzenlemeyi içerdiğini varsayın

Zamanla bu size hız için bir taban çizgisi verecektir. Her 5 puanlık hikaye diğerleriyle aynı zaman almayacak, ancak sprint başına ortalama hız (takımın kaç hikaye puanı tamamlayabileceği) tutarlı olacaktır.

Belirli bir hikayenin ne kadar zaman alacağından endişe etmek, karşı üretken. Tahminler yalnızca hacim olarak tutarlı bir şekilde boyutlandırılmış öyküler üzerinde ortalama (IE 5 işaretçisi yeniden düzenleme nedeniyle biraz daha uzun sürebilir, ancak ilgili çabanın faydasını alırsınız).

Orijinal iş öğesinin içinde ne kadar olduğu ve başka bir şeyin ne kadar olduğu konusunda göreceli bir kesme olmalıdır. Kullanıcı öyküleri tartışmalar için başlangıç ​​noktalarıdır ve bu nedenle bir öykü üzerinde çalışırken bir sprint sırasında çivilenecek her türlü kapsam öğesi olabilir.

Bir sprint planlamasında, bir kullanıcının yeni bir form istediği ve daha sonra gerçekçi olmayan 101 form değişikliğinin meydana gelebileceği "kapsam sürünmesini" önlemek için bir hikayenin ek kriterler ekleyebileceği zamanlar olabilir. bazen 2 haftalık bir sprint yapılır.

Akılda tutulması gereken bir yön, bu ekstra çalışmadan ne kadar değer kazanıldığıdır. Yapılabilecek tonlarca olası yeniden düzenleme olabilir, ancak tüm bu çalışmalar için herkes için ne kadar fayda var? Bu, ekibin iyi çalışmasına yardımcı olmak için bazı kuralların olması gerektiği, ancak kodu mükemmel hale getirmeye çalışırken kaybolmaması gereken yerdir.