Joel testi ne kadar güncel? [kapalı]


17

Ortaklarımı bir özelliğe sahip olmamız gerektiğine ve yeni kod yazmadan önce hataların düzeltilmesi gerektiğine ikna etmek istiyorum. Joel testine bakmalı mıyım ? Sizce Joel testi güncel mi? Spesifikasyona sahip olmamanın kötü proje yönetimi olduğunu düşünüyorum. Joel testine katılıyor musunuz? Bir şey ekler misiniz? Örneğin Açık Kaynaktan bahsetmiyor.


2
Joel Testi yazılım geliştirme ve geliştirici işe alma süreçlerine yöneliktir. Yazılımınızı lisanslama şekliniz veya kaynağınızı bununla ilgili olarak yayınlayıp yayınlamamanız nasıl?
Marjan Venema

Soru için teşekkürler Marjan. Joel testinin açık kaynaklandığından beri Açık Kaynak bir eğilim olduğunu düşünüyordum ve eğer birisi Açık Kaynak hakkında çok olumsuz olursa, muhtemelen bir ekibin açık kaynak koduna karşı olup olmadığını bilmek isterdim. Telif hakkı konularının kapsamın ötesinde olabileceğini kabul ediyorum, ancak programcı, açık kaynağın kaynağı görüntüleyebilmenin bir sorunu olduğunu ve ayrıca 13. soruda "Yedekleme sisteminiz var mı?" Olabileceğini düşünen bir ekiple çalışamaz. ve 14 "MD5'ten daha güçlü güvenliğiniz var mı?" cevaplar evet olmalı.
Niklas

1
Tamam, bu mantıklı. Açık kaynak çabaları sadece "tüketilmemeli", aynı zamanda kodla zorunlu olmasa da katkıda bulunmalıdır (parasal desteği düşünün). Yedekleme sistemleri önemlidir, ancak geliştirme ile sınırlı değildir ve bu nedenle bunları Joel testine eklemem. Ancak yedeklemeler hakkında hiçbir şey yapmayan bir iş ile görüştüysem, kapıya koşardım. Güvenlik Ben de eklemem. Yazılım tarafından geliştirilen güvenlik için bu bir endişe kaynağı olmayabilir (kurum içi uygulamalar) ve bu nedenle evet / hayır cevabına uyum sağlamaz, ayrıca güvenliğin gelişime özel olması gerekmez.
Marjan Venema

Bilgiyi benimle paylaştığın için teşekkürler. Yedeklemenin önemli olduğu, ancak geliştirmeye özgü olmadığı doğrudur.
Niklas

Birçok iyi soru, uzman deneyimine dayalı olarak bir dereceye kadar fikir üretmektedir, ancak bu sorunun cevapları gerçekler, referanslar veya spesifik uzmanlıktan ziyade neredeyse tamamen görüşlere dayanma eğilimindedir.
gnat

Yanıtlar:


23

Ben Joel testi güncel olduğunu düşünüyorum - "zamansız" diğer yazılım yazma kadar güncel.

Spesifikasyon olmadan ürün geliştirme (yazılım geliştirme dahil) yapmak sadece deliliktir.

Nereye gitmek istediğini nereden biliyorsun?

Spesifikasyon yazmakla ilgili tek bir noktaya değineceğim (aslında Joel'in spesifikasyonlarının çok iyi olduğunu düşünmüyorum ... hiç yoktan iyi, ama olabildiğince iyi değil). Bu nokta:

Spesifikasyon yazarken, nasıl yapılacağını değil, yalnızca ürünün ne yapması gerektiğini söyleyin.

Bu, bir spesifikasyondaki uygulama ayrıntılarını dikte etmediğiniz anlamına gelir. Bu bir tasarım etkinliği ve bunu tasarımcıların deneyimine ve yaratıcılığına bırakıyorsunuz.

[Bu kuralın yalnızca bir istisnası vardır: Bazen belirli bir uygulama ayrıntısı veya yöntemi zorunlu kılınmakta veya zorunlu kılınmakta, bu durumda uygulamaya konulmaktadır. Örneğin, yazılımın PHP ile yazılması gerekiyorsa ve bu pazarlık konusu değilse, spec. Bunun çok az örneği olmalı.]

Şunu da ekleyebilirim: hata izlemenin olmaması eşit bir delilik eylemidir. Bu sadece ameliyat için en profesyonelce ve aptalca bir yoldur ve büyük acı ve acıya yol açacaktır.


Çok hızlı ve değerli cevap için teşekkürler. Bana ulaşan bir delilik örneği, her şeyin aynı önceliğe sahip olması gerektiği ifadesiydi. Bu çılgın kuralların tersini yapmak başarıya yol açacaktır.
Niklas

4
"her şeyin eşit önceliği vardır" - "her şey # 1" olarak da bilinir. Açıkçası bu saçmalık. İŞE ZARAR açısından her şeye acımasızca öncelik verilmelidir. Sonra # 1 üzerinde çalışıyorsun. Herhangi bir nedenle # 1'de durdurulursanız # 2 üzerinde çalışırsınız. Ve bunun gibi. Herhangi bir nedenle # 1 üzerinde çalışamayan bazı insanlar varsa ve onlar # 9 - thats Tamam üzerinde iyi bir neden olması koşuluyla çalışma sonunda. ("Ben ve onun cooooooool gibi hissettim" iyi bir neden değil). Ayrıca yeniden öncelik vermek de uygundur. Haftalık olarak daha sık yapmak da delilik.
hemen

Bilgelik için teşekkürler. Her şeye öncelik verilmesi gerektiğine tamamen katılıyorum. Eşim de sorun olmamalı ve sorun izleyici olmamamız gerektiğini belirtti. Ancak sorunları belgelemenin doğru olduğunu ve pazar liderinin bile bir sorun izleyici tuttuğunu düşünüyorum. Yine, kuralın tersini yapmak işe yarayacak ...
Niklas

@ 909Niklas Muhtemelen başka bir ortak bulmalısın, gelecekteki hayatını daha rahat tutmak için ...
Marcel

+1 yalnızca: Bir özellik yazarken, nasıl yapılacağını değil, yalnızca ürünün ne yapması gerektiğini söyleyin.
Marcel

5

Burada şeytanın avukatını oynayacağım ve Joel Testinin güncel olmadığını önereceğim. Çok genel. Teknoloji olgunlaştıkça, sorular testi yazdığı zamandan daha spesifik olmalıdır.

Teknik özellikler belgeleri, kullanıcı hikayeleri ve Çevik geliştirme süreçlerimiz olduğu için en azından büyük ön-özellikli belgeler gerekli değildir. Bu soru "Dokümantasyon seviyesi tasarlanan çözümlere uygun mu?" Olarak değiştirilmelidir. Her iki haftada bir teslim edilen daha küçük, daha sıkı kullanıcı hikayeleri, çoğu durumda, ürünü ayrıntılı olarak açıklayan büyük bir ön belgeden çok daha yararlıdır. Bununla birlikte, bir sonraki Mars Rover'ı inşa ediyorsanız, ayrıntılı bir ön tasarım belgesi isteyebilirsiniz. Bir şirketin tasarım özellikleri olup olmadığını sorduysanız, "gerçekten değil, bunun yerine çevik süreçler ve kullanıcı hikayeleri kullanıyoruz" yanıtını duymak beni şaşırtmaz.

İkinci olarak, "günlük derlemeler" sorusu sürekli entegrasyon ile ilgili bir soruna dönüşmelidir. Oluşturulması saatler süren bir yazılım inşa etmedikçe (yerlerin% 99.99'u yapmayacaktır), soru şirketin sürekli entegrasyon kullanıp kullanmadığını sormalıdır.

Joel testinin çoğu gerçekten hiç çıkmadı. Hala çalışma ortamının bir göstergesini almak için iyi bir yoldur.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.