Çevik / Scrum ekibinizdeki hata iş akışı nedir?

Çevik / Scrum ekibinizdeki hata iş akışı nedir?

İşte bizimki: - Hata mevcut sprint'teki bir hikayeyle ilgiliyse, düzeltiriz. - Hata geçerli sprint'teki bir hikayeyle ilgili değilse ve kritik değilse, önceliklendirme için ürün sahibine gönderilir. - Hata sprint'teki bir hikayeyle ilgili değilse ve kritikse, düzeltiriz.

Mevcut sprint'teki çalışma ile ilgili herhangi bir şey düzeltildi, onları böcek olarak bile görmüyoruz ve bu şekilde yazmıyoruz. Sadece bir şeyi zaten Done olarak düşündüğümüz bir şeyin parçasıysa bir hata olarak düşünürüz.

Yeni bir hata ortaya çıktığında, biriktirme listesine ekleriz ve paydaşlarımız tarafından önceliklendiriliriz. Bir sprint'te kalan zamanımız varsa, daha düşük önceliğe sahip ancak kalan sürede tamamlayabileceğimiz bir şey olan daha kolay hatalarla mücadele etme eğilimindeyiz.

Her zaman bir hatanın sadece başarısız bir testi olan bir hikaye olduğunu düşündüm, bu nedenle özellikler için tipik ilk hikaye taslağından daha iyi tanımlandı.

Dolayısıyla, hataların hikayeler olduğuna ikna olduysanız, tahminler ve öncelikler konusunda onlara diğer hikayeler gibi davranırsınız.

Sanırım buna yaklaşmanın en iyi yolu, öncelikle bir Hatayı ne düşünmek istediğinizi belirlemektir.

Birçok geliştirici, şu anda üzerinde çalıştıkları bir hata değil, çünkü dürüstçe bir hata değil, amaçlandığı gibi çalışmayan bir şeyi düşünmeyecektir. Şu anda bir şey üzerinde çalışıyorsanız ve hala kusurları varsa, belirli bir hata aslında tam değildir, bu yüzden gerçek bir kusur yoktur. Ters, tamamlanmış iş için geçerlidir, eğer bir şeyin test / serbest bırakma / üretim için tamamlandığını ve hazır olduğunu belirlediyseniz ve daha sonra kodda veya kullanımda bir kusur bulursanız, kesinlikle bir hatayla karşılaşırsınız.

Şirketim, bir hatanın ne zaman düzeltilmesi gerektiğini belirlemek için aşağıdaki yöntemi kullanır:

Hata kritikse, ilgili ürünle ilgili geçerli sprint'e uygun önceliğe eklenir. Tipik olarak, bunu bir sprint haline getirmek için yaklaşık% 10 ekstra zaman planlıyoruz ve aslında tamamlamayı planlamadığımız ekstra şeylere sahip olmak istiyoruz, ancak herhangi bir hata yoksa veya bir şey beklediğimizden daha hızlı tamamlandıysa tamamlayınız.

Bir hata kritik değilse, bunu biriktirme listesine ekleriz ve normalde bir sonraki sprint'te tamamlarız.

neden bu ideal akış budur, bazı belirgin sızıntılar vardır ve bazen yönetimin düşündüğümüzden daha önce tamamlanması gerektiğine karar verirse, programlama açısından 'kritik olmayan' şeylerin hemen tamamlanması gerekebilir. Tamamlandı.

Bir yana, yapılacak en iyi şeyin bir yapı seçmek ve ona bağlı kalmak olduğunu düşünüyorum. Verimliliğin en büyük kayıplarından bazıları, yapısız şeyler yapmaya başladığınızda ortaya çıkar. Yapınızı bozmaya başladığınızda, yokuş aşağı gitmesi çok kolaydır.

Bu, sorunuza aşırı cevap vermiş olabilir, ancak bunlar sadece bu şeylerin nasıl ele alınması gerektiğine dair düşüncelerim.

Devam eden hata çalışmaları yapıyoruz. Kurulumunuza benzer şekilde, mevcut iş ile ilgili kritik bir sorun varsa, işi işin bir parçası olarak düzeltiriz. Sonuçta, eğer bir kusur varsa, "tamamlanmış" bir hikaye diyemezsiniz.

Diğer hatalar için genellikle zamanı izin verdiği şekilde düzeltiriz. Zorlayıcı sorunlar varsa, normal özellik çalışmalarına geri dönmeden önce bazı hikayeleri geri çeker ve hata düzeltmelerine zaman harcarız.

Sprint sırasında bulunan hatalar gelişimin sadece bir parçasıdır.

Sprint bittikten sonra bulunan hatalar Ürün İş Listesi'ne gider. Bir şeyin bir hata mı yoksa bir geliştirme mi yoksa bir değişiklik mi olduğunu asla kullanıcılarla tartışmayız. Kullanıcı bir hata olarak adlandırmak istiyorsa, o zaman para cezası, ama yine de PB'ye yeni bir iş çıkarıyor.