Sıfır hata / hata politikası ile çevik kalma

Projemizde sıfır hata (sıfır hata olarak da bilinir) yönteminde çalışıyoruz. Temel fikir, hataların her zaman öncelikli özelliklerden daha yüksek olmasıdır. Bir hikaye üzerinde çalışıyorsanız ve bir hatayı varsa, hikayenin kabul edilebilmesi için çözülmesi gerekir. Daha eski bir hikaye için sprint sırasında bir hata bulunursa, bunu bir sonraki işimize koyup çözmeliyiz - en öncelikli konu.

Çözme dememizin nedeni, her zaman hatayı düzeltmememizdir. Bazen o kadar da önemli olmadığı için "düzeltmeyeceğini" beyan ederiz. Hepsi bir arada harika görünüyor. Yüksek kaliteli ürünler gönderiyoruz ve büyük bir hata birikimi şeklinde "kambur" taşımıyoruz.

Ama bu yaklaşımın doğru olduğundan emin değilim. Her zaman en kısa sürede ciddi hataları düzeltmemiz ve ilginç olmayan hataları atmamız gerektiğine katılıyorum. Peki ya önemli ama yeni özellikler kadar önemli olmayan hatalar? İş yığınında uygun bir önceliğe sahip olmaları gerektiğini düşünüyorum.

Daha net olması için bir örnek vereceğim - projemde esnek olarak yazılmış bir kullanıcı arayüzü ile çalışıyoruz. Her ekran çözünürlüğü için aynı boyutta açılan bir sihirbaz ekranımız var. Sihirbaz penceresini genişlettiğimizde, sayfalardan birinin iyi görünmediği ortaya çıkıyor (sihirbaz şimdi her şeyi sunabilse ve kaydırma çubuğunu gerektirmemesine rağmen kaybolmayan dikey bir kaydırma çubuğu var). Bence bu böcek çirkin. Eminim düzeltilmelidir ZORUNLU. Ama sıkı bir programdayız ve korktuğumuz çok fazla özelliğimiz var, kesmeyi bırakmaya ve sürüme girmeyecek. Böyle bir böcekle yaşayabileceğimizi hissediyorum. Düzeltilmesi gerekiyor, ancak diğer özelliklerden daha düşük önceliğe sahip (yani, tamamlayamayacağımız takdirde, en azından daha önemli özellikleri dışarıda bırakmadık). Fakat,

"Düzeltmeyeceğim" olarak işaretlemek istemediğim hatalarla nasıl başa çıkılacağına dair fikirleri duymak isterim ama aynı zamanda çok da önemli değildir.

Yeni kod yazmadan önce hataları düzeltmek aslında Joel testinin on iki noktasından biridir . Joel ayrıca bunun neden olması gerektiğini de açıklıyor:

Genel olarak, bir hatayı düzeltmeden önce ne kadar uzun süre beklerseniz, o kadar pahalı (zaman ve para) düzeltmektir.

Bir seçeneğin var:

• Ya çok talep edilen bir özelliği uygular ve bir hatayı düzeltmeyi geciktirirsiniz, bu da kaçınılmaz olarak düzeltmenin maliyetini artıracaktır,

• Veya müşterilerin şu anda ihtiyaç duydukları özelliği sunma konusunda çok yavaş olduğunuzdan dolayı hayal kırıklığına uğrayacakları göz önüne alındığında hatayı düzeltin.

Hata çok önemli değilse, özellik olduğu sürece, yönetim ilk önce özelliği uygulamayı, sonra hatayı düzeltmeyi istemeye meyillidir. İş açısından bu, yönetimin sonuçları net bir şekilde anladığı sürece, yani hatayı düzeltmek artık daha zor olacaktır.

"Tüm hatalar düzeltilene kadar yeni özellik yok" seçeneğine bağlı kalmak en iyi iş seçimi olmayabilir. Sınırlılıklarından daha önce bahsetmiştiniz, bu yüzden açıklamaya gerek yok.

Bununla birlikte, küçük hataları düzeltmeden önce çok önemli özelliklerin uygulanmasına izin verme riskinin bir riski vardır: sınırları nereye koyacağız? 1000 müşterinin istediği bir özellik 100 müşterinin karşılaştığı bir hatadan daha mı önemlidir? Belirli bir hatayı düzeltmeden önce belirli bir özelliğin yapılması gerekip gerekmediği nasıl değerlendirilir?

Katı kurallar olmadan ve yönetim geliştirme sürecini çok iyi anlamıyorsa, birkaç yıl içinde sadece başka bir fantezi özelliğinden önce düzeltilmesi için yeterince önemli olmadığı düşünülen hatalarla dolu bir birikim ile kendinizi görebilirsiniz.

Durumunuzun belirli düşük seviyeli ayrıntılarına dalmanın yanı sıra, temel ve temel şeyleri doğru yaptığınızdan emin olmanız daha iyi olur.

Bu bağlamda, bahsettiğiniz politikanın "hataların her zaman özelliklerden daha öncelikli olduğuna" dikkat çekmenin çok önemli olduğuna inanıyorum, özellikle de kelime her zaman Agile Manifesto'da belirtilen dört ilkeden en az ikisinden sapıyor :

Bireyler ve süreçler ve araçlar üzerindeki etkileşimler

Bir planın ardından değişime tepki vermek

Ben çünkü, politika değişikliği gerektiğini ısrar etmeyin sıkıca inanmak biri olması gerektiğini çevik çevik ilkelerin çok uygulama hakkında.

Ama en azından olmalıdır farkında sen sapma ve sapma olup olmadığı ve anlamak zaman haklı . Basitçe söylemek gerekirse, "çevik" olarak adlandırdığınız şeyin aslında anlamsız sahte olmayacağından emin olmalısınız, bu yüzden etkili bir şekilde Yarım Kollu Agile Manifestosu ile kaplıdır :

Bireyler ve süreçler ve araçlar üzerindeki etkileşimler ve
bu bireylerin ('kaynaklar' terimini tercih ediyoruz) nasıl etkileşimde bulunduğunu kontrol etmek için zorunlu süreçlerimiz ve araçlarımız var

Yazılım kapsamlı bir şekilde belgelendiği
sürece, kapsamlı belgelere göre çalışan yazılım

Tabii ki sıkı sözleşmelerin sınırları dahilinde sözleşme müzakereleri üzerinden müşteri işbirliği
ve sıkı değişiklik kontrolüne tabi

Değişikliğe cevap vermek için ayrıntılı bir plan mevcut olması ve bir planın
tam olarak izlenmesi koşuluyla, bir planın ardından değişime yanıt vermek

Eksiklik uğruna, sıfır hata politikasının saptığı görünen sadece çevik ilkeler değildir.

Katıldığım çevik olmayan projelerde, programcıların yüksek öncelikli özelliklerin geciktirilmesini geciktirmeyi haklı çıkarmak için yeterince önemli olmayan hataları düzeltmeye zaman ayırmak genellikle akıllıca düşünülmedi .

Bu nedenle, yönetim genellikle hataların bir sonraki sürümde ne bekleyebileceğine karar vermek için bazı çabalar harcadı (belki de yatırım söylemek daha doğru olurdu ).

• ^{Şans eseri kritik yazılımlar üzerinde çalışıyor musunuz? Soruyorum çünkü bu durumda sıfır hata politikası oldukça mantıklı ve çevik / çevik olmayan / her hangi bir prensipten ödün vermeye değer. Bu durumda çevik bir süreci hayal etmeye çalışırken zorlanıyorum.}

Kritik görev yazılımı üzerinde çalışmadığınız sürece, yönetiminizin becerilerini ve düşünme yeteneklerini daha yakından değerlendirmenizi tavsiye ederim.

Demek istediğim, tarif ettiğiniz şeyden ziyade, hataları ve özellikleri düzgün bir şekilde önceliklendirmek için basitçe sınırsız oldukları görünüyor. Durum buysa, bu kadar rutin bir görevi yerine getiremezlerse, başka ne yapamazlar? Rekabetçi maaş sağlamak? kariyer büyüme fırsatları? çalışma şartları?

Haklı olarak belirttiğiniz gibi, sıfır hata politikası, kritik olmayan sorunların halının altında göz ardı edilmesi veya itilmesi riskine sahiptir, çünkü şimdi bunları çözmek için en iyi zaman değildir.

Yapabileceğiniz şey, yeni bir sorun bildirildiğinde, üç yollu bir karar vermek:

1. Bu gerçek bir hatadır ve en kısa zamanda düzeltilmelidir: birikmiş işin üstüne koy
2. Bu gerçek bir hatadır, ancak uygulamanın işleyişi için kritik değildir: düzenli bir hikayeye dönüştürün ve ürün sahibinin buna öncelik vermesini sağlayın.
3. Bu bir hata değil ya da bir kopya ya da çözmek için çaba harcamaya değmez: uygun bir sebeple reddetmek.

Bu şekilde, daha az önemli konular tamamen unutulmayacak, ancak aynı zamanda tüm yeni parlak özellikleri bir sonraki sprint'ten zorlamıyorlar. 'Bir hikayeye dönüştür', yönetimin sıfır hata politikası izlediğinizi iddia etmeye devam edebilmesi ve ürün sahibinin konunun önemini birikmiş iş yerindeki özelliklerin önemi ile dengeleyebilmesidir.

Bu prosedürle, bahsettiğiniz kaydırma çubuğu gibi sorunların projenin sonunda hala çözülemeyebileceğini unutmayın, ancak bunun nedeni, hiç kimsenin bunun (müşteriler dahil) yeterince önemli olduğunu düşünmediğinden değil, sorunun bulunduğu zaman.

Ben düzeni gibi, ancak, tanımladığınız gibi, çalışması için sadece küçük bir tweak gerekiyor - Gözlemlediğiniz gibi, gerçeklik genellikle yeni bir özellik bir hata düzeltme koz .....

Benim önerim hata önceliğini her sprint artırmak için zorlamaktır. Diyelim ki 5. seviyede bir hata var (ölçek 1-yüksek, 5 = düşük). 5, 4 sprint sonra başlar, bu bir seviye 1 hata. Ancak, öncelik hesaplaması için gerekli olan zihin seti, "Her bir sprint sonunda bekleyen hataların önceliğini artır" yerine "Mevcut öncelik - Sprint Sayısı" dır - bu, önceliği daha fazla ertelemek için "sıfırlama" nın düşük olmasını önler.

Seviye 1 hataları bir sonraki sprint'te ele alınmalıdır ...

Açıklamak basit, uygulaması kolay ....

Şimdi, istekleri belirtmek için, belki farklı bir oran. Bir süre sonra, talebin ele alınması gerekir - ya yapılır ya da atılır, değeri olmayan özelliklerin birikmesini önler ......

Her şeyin gerçekten kesilmesini ve kurutulmasını istediğimiz kadar, yazılım geliştirmedeki herhangi bir şey hakkında çok gerçek ya da kararlı olmaya çalıştığınızda sorun yaşarsınız. Yeni özellikler eklenmeden önce hataların düzeltilmesi gerekir, ancak yine de sorunun kapsamıyla birlikte bu kararı verirken her birinin önemini düşünürüm. Her şeyin istisnaları vardır.

Bazı uygulamalar o kadar büyüktür ki hiç alakalı olmayan bölümleri vardır. Borç hesapları modülünün her yeni özelliğinin neden beklemeye alınması gerektiğini görmüyorum, çünkü çalışan faydaları GUI'sında birkaç can sıkıcı hata var. Şirket web sitesinin satın alma bölümünde bazı sihirbaz adımı GUI sıkıntısı varsa, düzeltin, ancak eklenen özellik ek bir güvenlik, iş gereksinimi ve özellikle düzenlemelerdeki değişikliklerden kaynaklanıyorsa, birçok hatanın düzeltilmesi gerekebilir.

Zaman ve kaynaklardan birini tamamlamak için büyük bir tutarsızlık dışında, bazı kullanıcı / müşteri girişi elde etmek en iyisidir. Yeni özelliği almak anlamına gelirse hata ile yaşayabilirlerse, özelliği ekleyin. Amaç, hataların yığılmasına izin vermemek olmalı, bu yüzden bir boşluk bırakın. Bir noktada birçok küçük sorun büyük bir sorun haline gelir.

Testi çalıştırırken hatayı göstermek için testler yazmak hataları düzeltmek için iyi bir başlangıçtır. Ancak en az önceliğe sahip hataları düzeltmeye çalışırken, devam etmeden önce iki kez düşünmeliyiz. Düzeltmeyi atlamak istememiştim. Ancak bu hataları gidermek için kritik olmayan kaynakları kullanabiliriz. Diyelim ki ekibimde yeni kaynakları hata listesinde en az öncelikli hatalarla eğitiyoruz. Bu şekilde, yeni kaynağı eğitme ve uygulamaya girişlerinde bir düzeltme yaptıkları konusunda kendilerine güven tonu verme şansımız olur. Bu kesinlikle onları bir sonraki öncelikli görev için gönüllü yapacaktır.

Bu yardımcı olur umarım :)