Geliştirme ve kalite güvencesi arasında daha uzun gecikme maliyeti

Şu anki pozisyonumda KG bir darboğaz haline geldi. QA'nın testi bitirebilmesi için mevcut yapı dışında tutulan özelliklerin talihsiz oluşumunu yaşadık. Bu, geliştirilmekte olan özelliklerin, geliştirici zaten taşındıktan sonra 2-3 hafta boyunca test edilemeyeceği anlamına gelir. Geliştiriciler daha hızlı bir şekilde ilerledikçe, bu sefer boşluk daha da büyüyecek.

Kodlarımın tamamının kopyasını çevirmeye devam ediyorum, kusurları düzeltme maliyetinin katlanarak arttığını gösteren bir "Sabit Veri" snippet'i arıyorum. Birisi beni bu konsepti destekleyen bazı çalışmalara yönlendirebilir mi? Güçleri, QA darboğazının düşündüklerinden çok daha maliyetli olduğu konusunda ikna etmeye çalışıyorum.

Referansa ihtiyacınız yok, IMHO. Burada (daha doğrusu olabilir ne olmalıdır ) yapın:

Gecikme Maliyetini Belirleyin! Özelliklerin test edilmesinin 1 hafta sürdüğünü varsayalım. 2-3 haftalık bir gecikme, özelliğin en az 4. haftaya kadar kullanılamayacağını gösterir. Ve bu da% 100 başarı varsayıyor. Başka bir haftanın sabitleme süresini ekleyin, böylece yaklaşık 5 haftalık gecikme.

Şimdi, mümkünse projenin / özelliğin beklenen son tarihine erişin. Müşteri ne zaman beklemektedir? Kayar mı? Değilse, sonuç olarak diğerleri kayacak mı? Peki sonuç olarak 'tahliye' ne kadar gecikecek?

Bu sürüm için 'şirkete maliyet' nedir, yani müşteri bu sürümden ne kadar kâr elde etmeyi bekler? Eğer bu sürümden 5200 $ / yıl kar beklerlerse, o zaman her hafta kayıplar 100 $ kayıp gelir maliyeti. Müşteri görüşü budur. Bu verilere erişiminiz olabilir veya olmayabilir, ancak gecikmenin ilişkiyi nasıl etkileyebileceğini dikkate almaya ve belirtmeye değer.

Şimdi, geliştiricilerin kaybı nedir? Geliştirici diğer özelliklere geçtikten sonra, ondan döngüsünü kırmasını ve önceki özelliği 'düzeltmesini' istersiniz. Zaman / çaba kaybı nedir? Sonuç olarak her saatte bir harcanan maaşı çoklu olarak kullanarak maliyeti şirkete dönüştürün. Bunu, atığın "içine aldığı" kar / gelir "miktarını söylemek için kullanabilirsiniz.

Tökezledikleriniz, Ürün Geliştirme akışının ilkelerinde Don Reinerstein ve ayrıca Çevik Yazılım Gereksinimleri'nde Dean Leffingwell tarafından savunulan "Gecikme Maliyeti" kullanılarak rahatlıkla ölçülebilir. Sen ana dili olan $$ 'yüksek güçler' ikna ekonomik faktörler tarafından her tür iddiayı desteklemek gerekir - Eğer gerekir onları ikna etmek onların dilini :)

Şans canavarı! (kelime oyunu :)

Kod Tamamlama'nın burada sizin için doğru kaynak olduğunu düşünmüyorum . Bu bir kod sorunu değil, bir süreç sorunu ve belki de bir yönetim sorunu.

İşleminizin bir kısmı özellikle zayıfsa, o zaman Kısıtlar Teorisini bozma zamanı :

1. Kısıtlamayı belirleyin.

   Bu, tüm sürecin en yavaş veya en verimsiz kısmını bulmak anlamına gelir. Sizin durumunuzda, test ediyor. Ama testin hangi kısmı ? Bu mu:

   • Test ortamını hazırlıyor musunuz?
   • Neyi test edeceğinizi belirleme?
   • Fonksiyonel (kabul) testleri?
   • Regresyon testleri?
   • Keşif testi?
   • Testlerden kaynaklanan hataları / hataları raporlamak?
   • Bir hatayı yeniden oluşturma adımlarını belirleme?
   • Geliştiricilerden veya proje yöneticilerinden açıklama mı alıyorsunuz?
   • KG aşamasında bulunan sorunlar düzeltildi mi?

   Bunların hepsi çok farklı problemler ve farklı çözümler gerektiriyor. Hangisinin en pahalı / önemli olduğuna karar vermelisiniz. Yukarıdaki faaliyetlerin tümü zamana (AKA parası) mal olduğu ve sadece birkaçı katma değerli zaman olduğu için yönetime haklı göstermek zor olmamalıdır.

2. Kısıtlamayı kullanın.

   Başka bir deyişle, kısıtlama süreci etrafında optimize edin. Test cihazlarının boşta olmasına asla izin vermeyin. Bu esasen:

   • Test koymak içeride zaten değilse geliştirme ekipleri, bu yüzden geliştiriciler ile sürekli bir geri bildirim döngüsü vardır.
   • Sık sık test konuşlandırmalarına sahip olmak için, her zaman test edilecek yeni / sabit bir şey vardır.
   • İletişimi daha hızlı ve daha sık hale getirmek. Örneğin, e-posta dizileri üzerinden anlık mesajlaşmayı tercih edin.
   • Test cihazlarının mevcut en iyi araçlara sahip olmasını sağlamak (hızlı makineler, çoklu monitörler, kolaylaştırılmış hata izleme, vb.)

   Bu aşama, test sürecinin kendisini (henüz) optimize etmekle ilgili değil, daha çok ek yükü azaltmakla ilgilidir. Testçilerin zamanını boşa harcamayın. Gerçekten boşa harcanan zamanı ortadan kaldırmak da yönetim için kolay bir satış olmalıdır.

3. Diğer faaliyetleri kısıtlamaya tabi kılın.

   Bu noktada, test ediciler kendi başlarına olabilecekleri kadar verimlidirler, bu nedenle üretkenliği diğer alanlardan ödünç almaya başlamamız gerekir:

   • Geliştiriciler ve operasyon personeline, başka ne üzerinde çalışıyorlarsa çalışsınlar, test uzmanlarına öncelik vermelerini söyleyin.
   • Çapraz işlevli takımlarınız yoksa, her gün önceden belirlenmiş bir saatte bir toplantı odası rezerve edin, böylece test kullanıcıları asla kitap ayırmaya çalışırken zaman kaybetmek zorunda kalmazlar.
   • Geliştiricinin (ve muhtemelen işlemlerin) daha büyük bir yüzdesini özellik çalışmalarından uzaklaştırın; örneğin, hata düzeltmelerine, teknik borç / yeniden düzenleme, kod inceleme ve birim testlerine odaklanın.
   • Sürekli ve kademeli olarak test edin - 3 hafta boyunca gelişmeyin ve daha sonra test cihazlarına atın. Geliştiricilerin kodlarını derhal test edilebilir hale getirme konusunda çalışmasını sağlayın, örneğin iskele veya prototip kullanıcı arayüzleri gibi.

4. Kısıtlamayı kaldırın.

   Test uzmanları hem verimlilik hem de minimum ek yük açısından tam kapasitede çalışıyorsa ve hala yeterince hızlı değilse, teste daha fazla yatırım yapmaya başlamanız gerekir.

   • Manuel sınama dağıtımlarına güveniyorsanız, sürekli tümleştirme ve yapılandırma yönetimi komut dosyalarını kullanarak otomatikleştirin.
   • Test planlarının oluşturulması uzun zaman alıyorsa, daha iyi kabul kriterleri (örn. YATIRIM ) elde etmeye çalışın . Çoğu kuruluş başlangıçta bu konuda çok kötü.
   • Kabul testleri çok uzun sürüyorsa, otomatikleştirmeye başlayın. Salatalık veya FitNesse gibi bir araç kullanın veya gerekiyorsa xUnit türü testler yazın. UI testinin uzun sürmesi halinde Selenium, Watij ve diğer tarayıcı otomasyon araçları da vardır.
   • Regresyon testleri çok uzun sürüyorsa, bunu otomatikleştirin. O otomatik edilemezse, daha da büyük kod inceleme vurgu, birim test, statik analiz araçları, vb yani kapının kalitesini dışarı geliştirme üzerine odaklanmak Geliştiriciler çok az gerçek olduğunu oldukça emin olmalıdır böcek geçirmeden önce KG'ye (ürün kusurları farklı bir hikaye).
   • Keşif testi darboğazsa, potansiyel olarak yayınlanmasından sonraya kadar erteleyebilir veya aynı iş akışını birden fazla tarayıcıda test etmek gibi oldukça paralel hale getirilebilir şeyler yapmak için bir test firmasına başvurabilirsiniz.
   • Test kullanıcıları çok fazla hata üretemezse, aralıklı hatalar üretmeye başlayabilmek için bir kapasite test ortamı oluşturmayı düşünün. Ya da, otomatik kayıt testlerinizi gün boyu paralel ve sürekli olarak, ayrıntılı günlükleri tutmaya çalışın.
   • Hataları düzeltmek çok uzun sürüyorsa, projelerinizi bölümlere ayırmaya başlayın ve / veya çözümlerinizi tekrar araştırmayı düşünün. Veya alternatif olarak, bazılarını düzeltmeyin; her hata kritik değildir, özellik çalışmasının yanında bunlara öncelik verebilmelisiniz.
   • Her şey başarısız olursa daha fazla test kullanıcısı işe alın.

5. 1. Adıma geri dönün.

Tüm bunların sağduyu olduğunu söylemek isterim, ancak maalesef öyle değil, en azından çoğu kuruluşta değil. Yönetimden çok fazla direnç alıyorsanız, paha biçilemez bir teknik Değer Akışı Haritalamasıdır (yalın üretimden bir teknik), bu da bir yayınlama adayı tarafından her gün gerçekten ne kadar zaman harcandığını göstermek için kullanabilirsiniz. sonraki aşamaya geçmek. Fırsat maliyetini anlamak zordur, ancak bu onu görselleştirmek ve göstermek için bulduğum en iyi yollardan biridir.

Ve eğer bunların hiçbiri işe yaramazsa ... belki de işlevsiz bir şirkette olursanız, çok geç olmadan çıkın!

Ancak, bu sorunu sadece yöneticinin masasına birkaç kağıt bırakarak ve problemden para atmalarını isteyerek çözemezsiniz, çünkü (doğru) ona para atmanın aslında çözemeyeceğini ve hatta daha kötü. Çözümler sağlamanız gerekiyor ve bu da bununla ilgili. Sorunu, "daha fazla testçiye ihtiyacımız var" yerine "bu sorunu çözmeye başlamanın maliyet / fayda sırasına göre sıralamanın bir yolu" olarak tanıtırsanız, çok daha fazla başarı elde edersiniz.

Sayfa 29 ve 30'da aradığınız veriler bulunabilir, ancak bir takip gerekebilir.

Bu cümlede sayfa 30'da bahsedilen araştırmayı inceleyeceğim:

Düzinelerce şirket, bir projede daha sonra değil, daha önce kusurları düzeltmeye odaklanmanın, geliştirme maliyetlerini ve zamanlamalarını iki veya daha fazla faktörle azaltabileceğini bulmuştur (McConnell 2004).

BTW, beni yenilemek için kitabı tekrar almamı sağlayan sorunuz buydu :-)

Açıkladığınız şey bir süreçteki bir darboğazdır. Yalın teori, bir süreçte her zaman bir darboğaz olacağını, ancak şiddetinin büyük ölçüde değişebileceğini belirtir. KG bir ekstra kiraladıysa, geliştirme darboğaz haline gelebilir.

Maliyeti anlamak için aşağıdaki durumu hayal edin. Geliştiricilerden birini seçtiniz. Çalışmaları asla Kalite Güvencesi olmayacaktır, ancak daima süresiz olarak sıraya alınacaktır. Bunun QA'nın Kalite Geliştiricilerinin geri kalanının çalışmalarını zamanında sağlayabileceği ve gecikme maliyeti olmayacağı anlamına geleceğini düşünün.

Bu senaryoda, gecikmenin maliyeti geliştiricinin maaşının maliyetidir, çünkü çalışmaları boşa harcanacaktır.

Süreç tarafından yaratılan değer değil maliyet açısından tartışmamın nedeni, daha iyi olmasına rağmen, bir sürecin değerini belgelemenin daha zor olmasıdır.

Kodlarımın tamamının kopyasını çevirmeye devam ediyorum, kusurları düzeltme maliyetinin katlanarak arttığını gösteren bir "Sabit Veri" snippet'i arıyorum. Birisi beni bu konsepti destekleyen bazı çalışmalara yönlendirebilir mi?

Bir hata bulmanın üstel maliyeti, bir NIST çalışmasına dayanıyor gibi görünmektedir . Çalışma, farklı şelale aşamalarını varsaydığı bir anketti:

Software Development Stage         | Cost
-----------------------------------+------
Requirements and Design            | 1X
Code and Unit Testing              | 5X
Integration and System Testing     | 10X
Beta Testing                       | 15X
Post Release                       | 30X

( buradan tablo )

Çevik yazılım geliştirme metodolojilerinin amaçlarından biri, bu farklı aşamaları ortadan kaldırmak ve bu maliyetleri azaltmaktır. Rakamlar şelaleye başka metodolojiler kullanıldığında geçerli değildir.

Probelminiz QA ile değil, aslında QA'nız Test yapıyorsa, gecikmeler neredeyse endişelerinizden en az. Lütfen açıklamama izin verin (yine, Programlama endüstrisindeki yaygın yanlış anlama) ... KG Kalite, SDRL'nin tamamını Gereksinimlerden (belki daha önce), geliştirme, doğrulama, serbest bırakma ve destek yoluyla denetleyerek ürünün kalitesini garanti eder. Test, kodda belirgin bir kusur bulunmamasını sağlar. Çok büyük ve önemli bir fark var. Gerçek bir KG'niz olsaydı, Test / V&V departmanının her yerinde, neden iş zamanını (ve dolayısıyla parayı) geciktiren gecikmeleri maliyetlendirdiklerini veya proje planlamasını düzgün bir şekilde yönettiklerini gösteren tüm proje yönetimini veya tüm yönetim yapmayı soruyorlardı. emin olunan kod vb için yeterli test edildi ...

Yani QA tarafından varsayıldığında, orijinal soruya geri dönmek için gerçekten Test demek istediniz. Kod Tamamlandı bunu doğru yaptı - bir hatanın maliyeti, yerleştirmeden düzeltmeye kadar geçen süredir. Erken teşhis sadece erken düzeltirseniz yararlıdır, ancak çoğu insan yorumu yanlıştır.

(Not: Burada Devils savunucusu oynuyorum, hiçbirini bilmediğin gibi kelimenin tam anlamıyla almayın) Test departmanınızın gecikme sebebi bir maliyettir, ancak, sormak zorundayım, eğer kusurlarını bulmalarını bekliyorsun, ne yapıyorsun - kendi kusurlarını bulamıyor musun? Belki daha az çalışmalarına sahip olsaydı (sizden daha az kusurlu daha yüksek kaliteli girdi yoluyla), gecikme önemli olmayacak ve maliyet daha az olacaktır - bir yönetici olarak, teslim ettiğiniz koddaki kusurları nasıl azaltmayı planladığınızı soracağım test, (argümanınıza dayanarak), bu kusurların test tarafından kendiniz sonra bulunması durumunda daha pahalıya mal olur.

Ayrıca yöneticiniz olarak, Testlerin iş kusurlarınızı bulmadıklarını söyleyebilirim, İşleri kusur olmadığını bulmaktır - eğer kusurları bulmalarını bekliyorsanız, belki de işinizi yeterince iyi yapmadınız.

Buna nasıl yaklaştığınıza dikkat edin. Soruna bir çözümünüz yoksa, muhtemelen en iyi ikinci olasılıktan çıkacaksınız.