คุณคิดอย่างไรเกี่ยวกับการทดสอบ Joel [ปิด]


51

การทดสอบ Joelเป็นการทดสอบที่รู้จักกันดีในการพิจารณาว่าทีมของคุณดีแค่ไหน คุณคิดอย่างไรเกี่ยวกับคะแนน คุณไม่เห็นด้วยกับพวกเขาหรือไม่? มีอะไรที่คุณจะเพิ่มหรือไม่

คำตอบ:


41

Jeff Atwood มีบิลของโปรแกรมเมอร์สิทธิ

จากโพสต์:

  1. โปรแกรมเมอร์ทุกคนต้องมีจอภาพสองจอ
  2. โปรแกรมเมอร์ทุกคนจะต้องมีพีซีที่รวดเร็ว
  3. โปรแกรมเมอร์ทุกคนจะต้องเลือกใช้เมาส์และคีย์บอร์ด
  4. โปรแกรมเมอร์ทุกคนต้องมีเก้าอี้นั่งสบาย
  5. โปรแกรมเมอร์ทุกคนจะต้องมีการเชื่อมต่ออินเทอร์เน็ตที่รวดเร็ว
  6. โปรแกรมเมอร์ทุกคนจะต้องมีสภาพการทำงานที่เงียบ

ดูเหมือนว่าจะมีบางรายการที่ฉันต้องการเห็นในรายการของ Joel โดยเฉพาะอย่างยิ่งในพื้นที่ของฮาร์ดแวร์ (จอภาพสองเครื่องคอมพิวเตอร์ที่รวดเร็ว, เมาส์ / คีย์บอร์ด, เก้าอี้ที่สะดวกสบาย, การเชื่อมต่อที่รวดเร็ว)

สิ่งเดียวที่ไม่ได้กล่าวถึงจะมีความสะดวกสบายและการปรับโต๊ะเขียนหนังสือ

ทั้งหมดนี้สามารถเพิ่มได้โดยการเปลี่ยน:

ปัจจุบัน # 9: คุณใช้เครื่องมือที่ดีที่สุดที่เงินสามารถซื้อได้หรือไม่?

ไปยัง

ปรับปรุง # 9: คุณใช้เครื่องมือและอุปกรณ์ที่ดีที่สุดเท่าที่เงินสามารถซื้อได้หรือไม่?


# 6 ของคุณไม่เหมือนกับ # 8 ในการทดสอบ Joel:
HerbN

มันเป็น # 6 ของ Jeff Atwood และใช่มันเป็น
spong

ดูเหมือนว่า Joel Test นั้นมีความเฉพาะเจาะจงมากขึ้นในการช่วยให้โปรแกรมเมอร์พัฒนาซอฟต์แวร์ที่สะอาดปราศจากข้อผิดพลาดซึ่งต่างจากสภาพการทำงานยกเว้น # 8
Archmede

13

มันน่าสนใจที่ตอนที่ 8 อ่านแล้ว:

8. Do programmers have quiet working conditions?

เมื่อมันเคยอ่าน (คล้าย)

8. Do programmers have their own office?

และย่อหน้าสุดท้ายยังคงเริ่มต้น:

ตอนนี้เราจะย้ายพวกเขาไปยังสำนักงานแยกต่างหากด้วยกำแพงและประตู

ฉันมักจะสงสัยการทดสอบนี้เช่นเดียวกับในทุกสถานที่ที่ฉันเคยทำงาน - ทั้งในฐานะพนักงานและผู้มาเยี่ยม - คนเดียวที่มีสำนักงานของตัวเองคือกรรมการและผู้จัดการอาวุโส

การเขียนซอฟต์แวร์ในโลกแห่งความจริงมักจะเป็นกิจกรรมของทีมคุณต้องพูดคุยกับเพื่อนร่วมทีมของคุณเพื่อตีกลับความคิดรอบตัวเป็นต้นและนั่นยากที่จะทำกับผู้คนในสำนักงานแยกต่างหากแม้กับระบบส่งข้อความด่วน ความสามารถในการดึงสิ่งต่าง ๆ ออกมาและแสดงรหัสผู้คนและไดอะแกรมนั้นช่วยได้มาก นี่ไม่ได้เป็นการบอกว่าทีมที่แจกจ่ายไม่สามารถทำงานได้ - พวกเขาสามารถทำได้และเห็นได้ชัดว่าเป็นปัญหาที่แตกต่าง

สิ่งที่ฉันจะพูดคือแต่ละทีมจะต้องอยู่ในสำนักงานของตัวเอง 6-8 คน (สมมติว่าเป็นขนาดของทีม) ด้วยวิธีนี้พวกเขาสามารถโต้ตอบโดยไม่รบกวนทีมอื่น ๆ (ถ้ามี) และทำงานต่อโดยไม่ถูกรบกวนจากทีมขายหรือผู้เข้าชม (ที่เดียวที่ฉันทำงานคุณมาผ่านประตูหน้าตรงเข้าไปในพื้นที่พัฒนา)

ถ้าคุณกำลังทำงานกับนักพัฒนาอื่น ๆ แต่แต่ละคนจะทำงานในโครงการที่แยกต่างหากจากนั้นสำนักงานที่ใช้ร่วมกันสามารถเป็นประโยชน์ - แต่ถ้าคุณเป็นคนที่เข้มงวดเกี่ยวกับการประชุมไปที่ห้องประชุมและกำหนดเวลาที่เคารพของคนอื่น ๆ ฯลฯ

ส่วนใหญ่เป็นความจริงที่ชัดเจนของตนเอง


9
ปัญหาในการสะท้อนความคิดเห็นจากเพื่อนร่วมทีมคือการถามพวกเขาด้วยวาจาเป็นสิ่งที่ทำให้ไขว้เขว หากคุณต้องการทำงานร่วมกันอย่างจริงจังจากนั้นทำงานในพื้นที่การทำงานร่วมกัน แต่สำหรับคำถาม "เฮ้คุณจะทำอย่างไร" คุณจะรู้สึกดีขึ้นมากเมื่อใช้ IM
Matt Olenik

@Matt - สำหรับสิ่งเล็ก ๆ น้อย ๆ ที่คุณพูดถูก แต่พื้นที่สำนักงานขาดแคลนเสมอ - ไม่มี บริษัท ไหนอยากใช้เงินกับสำนักงานที่ว่างเปล่า - ซึ่งเป็นเหตุผลว่าทำไมการมีทีมในพื้นที่ของตัวเองช่วย คุณสามารถเปลี่ยนสำนักงานให้กลายเป็น "พื้นที่การทำงานร่วมกัน"
ChrisF

2
คุณไม่สามารถหมายถึงแปดคนในห้องเดียวกันได้ไหม ฉันรำคาญแล้วโดยการแชร์ห้องกับโปรแกรมเมอร์อื่น ๆ สามคน (แต่ละคนทำงานในสิ่งที่ตัวเองมีอยู่คนหนึ่งทำงานในโปรเจ็กต์ที่ไม่เกี่ยวข้องอย่างสมบูรณ์และอีกอันหนึ่งเป็นแบ็กเอนด์ / ฐานข้อมูล) ฉันรู้แน่นอนว่าถ้าฉันแชร์ห้องกับผู้ชายอีกเจ็ดคนฉันจะส่งไปรษณีย์
Baelnorn

1
@ChrisF: อาจเป็นปัญหา พวกเราสี่คนนั่งอยู่ในห้องเดียวกันแทบจะไม่มีอะไรเกี่ยวข้องกับการเขียนโปรแกรมอย่างชาญฉลาด มันเป็นเหมือน 4 คนที่ทำงานใน 2 1/2 โครงการนั่งอยู่ในห้องเดียวกัน และตอนนี้เพิ่มเจ้านายที่อย่างไม่คิดถือการอภิปรายนานครึ่งชั่วโมงกับอีกโปรแกรมเมอร์ขวาถัดไปที่โต๊ะทำงานของคุณแม้จะมีห้องประชุมเป็นเพียงข้ามห้องโถง >. <
Baelnorn

1
@ChrisF - "การเขียนซอฟต์แวร์ในโลกแห่งความจริงเป็นกิจกรรมของทีมคุณต้องพูดคุยกับเพื่อนร่วมทีมของคุณเพื่อตีกลับความคิดรอบ ๆ ฯลฯ และนั่นยากกว่ามากสำหรับผู้คนในสำนักงานแยกต่างหาก" - ดังนั้นทีมพัฒนาจึงแผ่กระจายไปตามสถานที่ต่างกันอย่างไร ฉันทำงานอย่างใกล้ชิดกับผู้คนทั่วสหรัฐอเมริกาหรือบราซิลหรืออินเดีย - IM และ Adobe Connect - รวมถึงที่อยู่ร่วมกันตั้งแต่ทีมเล็กไปจนถึงทีมใหญ่ คุณเป็นสภาพแวดล้อมที่ก่อกวนมาก การทำงานเป็นทีมสามารถทำได้อย่างมีประสิทธิภาพ แต่สิ่งที่คุณกำหนดคืออะไร แต่ (ความคิดของคุณถูกต้องจากการตกยุค 70)
luis.espinal

10

ฉันชอบ แต่ถ้าฉันใช้เพื่อประเมิน บริษัท ฉันจะไม่ชั่งน้ำหนักรายการทั้งหมดเท่า ๆ กัน ไม่มีการควบคุมแหล่งที่มาเป็นปัญหาที่ใหญ่กว่านั้นไม่ซื้อเครื่องมือที่ดีที่สุดที่เงินสามารถซื้อได้


9

ดีลเลอร์คนเดียวสำหรับฉันคือ:

 8. Do programmers have quiet working conditions?

ที่น่าสนใจคือคำถามที่มักจะล้มเหลวโดยการโพสต์งานซ้อนมากเกินไป

คำถามบางข้อนั้นยากที่จะล้มเหลวโดยเฉพาะอย่างยิ่งหากมีโปรแกรมเมอร์มากกว่าหนึ่งคนใน บริษัท :

 1. Do you use source control?
 2. Can you make a build in one step?
 4. Do you have a bug database?

คนอื่น ๆ ส่วนใหญ่ที่ฉันไม่สนใจ ฉันหมายถึงโดยสุจริต:

12. Do you do hallway usability testing?

มีสิ่งหนึ่งที่จะตรวจจับคนโกหก:

 5. Do you fix bugs before writing new code?

20
ฉันคิดว่าคุณจะประหลาดใจที่มี บริษัท ไม่สามารถสร้างได้ในขั้นตอนเดียวและไม่มีฐานข้อมูลบั๊ก คุณอาจถูกต้องเกี่ยวกับการควบคุมแหล่งที่มา แต่ฉันขอยืนยันว่า บริษัท จำนวนมากใช้เพียงเพื่อสำรองข้อมูลรหัสของพวกเขาและไม่แม้แต่จะขีดข่วนพื้นผิวของประโยชน์ของการควบคุมแหล่งที่มา
Rob Sobers

1
เมื่อฉันเริ่มงานปัจจุบันของฉันเรามีระบบควบคุมแหล่งที่มา แต่งานสร้างเสร็จแล้วในเครื่องของผู้ชายคนหนึ่งและมีเพียงเขาเท่านั้นที่รู้ทุกขั้นตอนและมีการติดตามข้อบกพร่องบนกระดาษ สิ่งเหล่านี้ทั้งหมด "คงที่" ตอนนี้ แต่ฉันไม่เคยใช้สิ่งเหล่านี้เพื่อรับสิทธิ์
HappyCat

6

ฉันต้องบอกว่ามันเป็น "พื้นฐาน" ที่ดี แต่ด้วยเครื่องมือวัดใด ๆ ก็มีปัจจัยอื่น ๆ ตัวอย่างเช่นไม่ใช่ บริษัท เดียวที่ฉันทำงานให้เสร็จได้ทำ Build รายวัน (ฉันรู้ว่าฉันรู้) แต่บาง บริษัท ก็ทำได้ดีมาก

ฉันมีรายการอื่น ๆ ที่ฉันต้องการเพิ่มในรายการ

  1. คุณสนับสนุนการศึกษาของนักพัฒนาโดยเข้าร่วมการประชุมซื้อหนังสือหรืออะไรที่เป็นลักษณะนั้นหรือไม่?
  2. คุณมีกระบวนการที่เรียบง่ายและเป็นเอกสารในการปรับใช้เครื่องมือใหม่ ๆ หรือไม่หากจำเป็นเพื่อทำหน้าที่งานให้สมบูรณ์
  3. คุณให้อุปกรณ์ของนักพัฒนาและสภาพแวดล้อมที่จะช่วยให้พวกเขามีประสิทธิผล

มากกว่าสิ่งเหล่านี้เป็นรายการที่มี "ฉี่ฉันออก" จากนายจ้างก่อนหน้านี้และตอนนี้พวกเขาเป็นคำถามที่ติดตามอย่างรวดเร็วที่ฉันถามเกี่ยวกับทุกโอกาส


1
มี 3 รายการอยู่ในรายการแล้วหรือยัง
Casebash

ใช่ในรูปแบบใดรูปแบบหนึ่ง แต่ฉันเขียนรายการของฉันแตกต่างออกไปเล็กน้อยดังนั้นฉันจึงทิ้งมันไว้ที่นั่น
ผู้ขาย Mitchel

5

ฉันเห็นด้วยกับคะแนนส่วนใหญ่ของโจเอล ฉันไม่แน่ใจเกี่ยวกับ "การทดสอบการใช้งานห้องโถง" การทดสอบการใช้งานแน่นอน แต่จริง ๆ แล้วจับใครบางคนจากโถงทางเดินและทำให้พวกเขาทดสอบโปรแกรมของคุณแม้ว่าจะไม่ใช่งานของพวกเขา นั่นเป็นวิธีที่ดีในการทำเครื่องหมายคน


1
แน่นอนว่ามันเป็นเรื่องทางวัฒนธรรม - ถ้ามันไม่ได้ก่อกวนมากเกินไปและถ้ามันเป็นส่วนหนึ่งของวิธีการทำธุรกิจก็ไม่ควร "ติ๊กคนออก" - โดยเฉพาะอย่างยิ่งถ้าวัตถุประสงค์ของธุรกิจคือการพัฒนาแอปพลิเคชัน
Murph

1
บางทีประเด็นคือควรเป็นส่วนหนึ่งของงานของคนอื่นหรือไม่?
JeffO

7
จุดรวมของการทดสอบการใช้งานห้องโถงคือต้องเป็นคนที่ไม่ได้ใช้โปรแกรมอย่างสม่ำเสมอ เมื่อคุณสร้างมันขึ้นมาและ / หรือใช้เวลาหลายชั่วโมงในการใช้มัน (เช่นผู้ทดสอบเฉพาะ) มุมมองของคุณในแอปจะถูกบิดเบือน
GSto

5

การทดสอบ Joel ไม่ได้ทดสอบว่าทีมดีแค่ไหน มันทดสอบว่าทีมของคุณปฏิบัติตาม Joel Test ได้ดีเพียงใด

นี่คือการทดสอบที่ดีขึ้นว่าทีมของคุณดีแค่ไหน ฉันเรียกมันว่าการทดสอบ GrandmasterB มันมีคำถามหนึ่งข้อ

1) ซอฟต์แวร์ที่คุณเขียนดีหรือไม่?

มันไม่เกี่ยวข้องกับฉันไม่ว่าคุณจะ 'การทดสอบห้องโถง' หรือไม่หรือการควบคุมแหล่งที่คุณมีหรือสิ่งที่กระบวนการสร้างของคุณคือ (ถ้ามีอย่างใดอย่างหนึ่ง - ไม่ใช่ lanugage ทุกคนมีพวกเขา) การวัดที่แท้จริงของทีมคือคุณภาพของซอฟต์แวร์ที่พวกเขาสร้าง

โดยทั่วไปคุณสามารถทำตามทุกขั้นตอนของการทดสอบ Joel และยังคงจบลงด้วยรหัสอึและผลิตภัณฑ์ที่ไม่เคยจัดส่ง ตัวอย่างเช่นการควบคุมแหล่งที่มาไม่ได้ทำให้ coder ที่ดีขึ้นอย่างน่าอัศจรรย์; มันทำให้การจัดการรหัสง่ายขึ้น และมีรุ่นล่าสุดของ Visual Studio ไม่ได้หมายความว่าใบสมัครของคุณจะทำงานได้ดีกว่าถ้ามันถูกเขียนด้วยVisual Studio 2005


14
คุณไม่มีจุด การทดสอบ Joel ไม่ได้เกี่ยวกับซอฟต์แวร์ที่ดีเพียงใด แต่เกี่ยวกับประสิทธิภาพของกระบวนการผลิต ทีมที่ล้มเหลวในการทดสอบ Joel อาจยังคงสร้างผลิตภัณฑ์ที่ดี แต่โอกาสที่จะใช้เวลานานกว่านั้นมากและคนงานจะต้องทนทุกข์ทรมาน เครื่องมือไม่ได้หมายถึงซอฟต์แวร์เท่านั้น มันยังหมายถึงฮาร์ดแวร์จากคอมพิวเตอร์ของคุณจนถึงโต๊ะทำงานและคีย์บอร์ด
Matt Olenik

ฉันคิดว่าคุณไม่มีจุด หากทีมทำโครงการให้เสร็จทันเวลาและผลิตซอฟต์แวร์ที่มีคุณภาพดีพวกเขาจะต้องมีประสิทธิภาพ และพวกเขามีกระบวนการที่มีประสิทธิภาพตามนิยาม
GrandmasterB

2
คุณไม่เคยพูดถึงการจัดส่งตรงเวลา นอกจากนี้ฉันรู้สึกประหลาดใจอย่างยิ่งที่เห็นทีมที่มีประสิทธิภาพซึ่งล้มเหลวในการทดสอบ Joel สิ่งต่าง ๆ เช่นการควบคุมเวอร์ชันการทดสอบและการใช้งานล้วนเป็นสิ่งสำคัญ รายการอื่น ๆ อาจเป็นอุปสรรคที่ค่อนข้างใหญ่เช่นกัน
Matt Olenik

นี่เป็นจุดที่ดี แต่จุดอ่อนหลักคือความเป็นส่วนตัวของมัน ทุกคนอาจมีความเห็นที่แตกต่างกันเกี่ยวกับคุณภาพซอฟต์แวร์ขึ้นอยู่กับประสบการณ์ระดับทักษะและมุมมองการใช้งาน แต่ฉันชอบประเด็นนี้
Bernard Dy

หากกระบวนการที่มีประสิทธิภาพของพวกเขาจะมีผลเฉพาะกับสมาชิกที่อยู่ในทีมโดยเฉพาะอย่างยิ่งถ้าทีมมีขนาดเล็กมันจะดีต่อการเติบโตหรือในกรณีที่เกิดภัยพิบัติหรือเกษียณอายุก่อนกำหนด? ความสามารถในการสร้างรหัสที่ทำงานได้ดีและส่งมอบตรงเวลาผ่านกระบวนการที่มีอยู่ในหัวของคนที่พัฒนามันเป็นสูตรสำหรับภัยพิบัติทีมที่ไม่ช้าก็เร็ว (อาจจะเร็วกว่า) จะเผชิญกับปัญหาที่คนส่วนใหญ่ ไม่สามารถหรือไม่ต้องการกู้คืน
Finni McFinger

5

แม้ว่าฉันคิดว่ามันสมเหตุสมผลดีในความหมายทั่วไป แต่ฉันก็พบว่ารายการค่อนข้างตรงกับประเภทของซอฟต์แวร์เฉพาะที่Fog Creek Softwareทำ ( หดตัวลง ) ที่ไม่น่าแปลกใจจริงๆในขณะที่เขายังพูดถึงเกี่ยวกับที่โพสต์อีกห้าโลก และมีการพัฒนานอกโลกมากมาย

มีเงื่อนไขบางประการที่ไม่สมเหตุสมผลหากคุณพัฒนาเช่นซอฟต์แวร์ฝังตัวสำหรับดาวเทียมหรือเครื่องขายแสตมป์อัตโนมัติเช่นการสร้างรายวัน (3) หรือการทดสอบการใช้งาน (12)


ตกลง เมื่อคุณย้ายออกจากแอพ "สุดยอดสแต็ค" แนวคิดร่วมสมัยจำนวนมากดูเหมือนจะกลายเป็นเรื่องเล็กน้อย ... ไม่เกี่ยวข้อง
พอลนาธาน

ฉันเห็นด้วย. มีงานพัฒนามากมายในร้านไอทีขององค์กร ... แน่นอนว่าไม่น่าดึงดูดเท่ากับการหดห่อ เนื่องจาก บริษัท เหล่านี้ส่วนใหญ่ไม่ได้อยู่ในธุรกิจซอฟต์แวร์ บริษัท ส่วนใหญ่จึงมักจะให้คะแนนประมาณ 4 ในการทดสอบ Joel
Bernard Dy

6
ทำไมคุณไม่สร้างการทดสอบหน่วยสำหรับซอฟต์แวร์ฝังตัว (และให้พวกเขาทำงานโดยอัตโนมัติโดยระบบสร้าง)
ปีเตอร์มอร์เทนเซ่น
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.