การทดสอบ Joel ทันสมัยแค่ไหน? [ปิด]


17

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


2
Joel Test มุ่งเน้นไปที่การพัฒนาซอฟต์แวร์และกระบวนการจ้างนักพัฒนา วิธีการที่คุณให้สิทธิ์ใช้งานซอฟต์แวร์ของคุณหรือไม่ว่าคุณจะทำหรือไม่เผยแพร่แหล่งข้อมูลที่เกี่ยวข้อง
Marjan Venema

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

1
ตกลงที่เหมาะสม ความพยายามของโอเพ่นซอร์สไม่เพียง แต่จะ "สิ้นเปลือง" เท่านั้น แต่ยังต้องมีส่วนร่วมด้วยแม้ว่าจะไม่จำเป็นต้องใช้รหัส ระบบสำรองข้อมูลมีความสำคัญ แต่ไม่ จำกัด เฉพาะการพัฒนาดังนั้นฉันจะไม่เพิ่มลงในการทดสอบ Joel แต่ถ้าฉันสัมภาษณ์กับธุรกิจที่ไม่ได้ทำอะไรเลยเกี่ยวกับการสำรองข้อมูลฉันจะวิ่งหาประตู ความปลอดภัยฉันจะไม่เพิ่มอย่างใดอย่างหนึ่ง สำหรับซอฟต์แวร์ที่ได้รับการพัฒนาด้านความปลอดภัยนั้นอาจไม่ใช่เรื่องกังวล (แอพภายในองค์กร) และดังนั้นจึงไม่ให้ยืมตัวเองเพื่อคำตอบที่ใช่ / ไม่ใช่รวมถึงความปลอดภัยไม่จำเป็นต้องพัฒนาเฉพาะเจาะจง
Marjan Venema

ขอบคุณสำหรับการแบ่งปันความรู้กับฉัน เป็นเรื่องจริงที่การสำรองข้อมูลมีความสำคัญ แต่ไม่ใช่การพัฒนา
Niklas

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

คำตอบ:


23

ฉันคิดว่าการทดสอบ Joel นั้นทันสมัย ​​- มันเป็นข้อมูลล่าสุดของซอฟต์แวร์อื่น ๆ ที่เขียนว่า "ไร้กาลเวลา"

การพัฒนาผลิตภัณฑ์ (ซึ่งรวมถึงการพัฒนาซอฟต์แวร์) โดยที่ไม่มีข้อมูลจำเพาะเป็นเพียงเรื่องบ้าคลั่ง

คุณรู้ได้อย่างไรว่าคุณต้องการไปที่ไหน

มีเพียงจุดเดียวที่ฉันจะทำเกี่ยวกับการเขียน spec (จริง ๆ แล้วฉันไม่คิดว่ารายละเอียดของ Joel ดีมาก ... ดีกว่าไม่มีอะไร แต่ไม่ดีเท่าที่ควร) จุดนั้นคือ:

เมื่อเขียนสเป็คให้พูดเฉพาะสิ่งที่ผลิตภัณฑ์ต้องทำไม่ใช่ว่าจะต้องทำอย่างไร

ซึ่งหมายความว่าคุณจะไม่บอกรายละเอียดการใช้งานในข้อมูลจำเพาะ นั่นเป็นกิจกรรมการออกแบบและคุณปล่อยให้ประสบการณ์และความคิดสร้างสรรค์ของนักออกแบบ

[มีข้อยกเว้นเพียงข้อเดียวสำหรับกฎนี้: บางครั้งรายละเอียดการใช้งานหรือวิธีการบางอย่างได้รับคำสั่งหรือจำเป็นซึ่งในกรณีนี้จะใส่ไว้ตัวอย่างเช่นหากซอฟต์แวร์ต้องเขียนใน PHP และไม่สามารถต่อรองได้ สเป็ค ควรมีกรณีนี้น้อยมาก]

ฉันอาจเพิ่ม: ไม่มีการติดตามข้อผิดพลาดเป็นการกระทำของความบ้าคลั่งเท่ากัน เป็นวิธีที่ไม่เป็นมืออาชีพและโง่ที่สุดในการดำเนินการและจะนำไปสู่ความเจ็บปวดและความทุกข์ทรมาน


ขอบคุณสำหรับคำตอบที่รวดเร็วและมีคุณค่า อีกตัวอย่างของความบ้าคลั่งที่มาถึงฉันคือข้อความที่ทุกสิ่งควรมีความสำคัญเท่ากัน รู้สึกเหมือนทำสิ่งที่ตรงกันข้ามกับกฎที่บ้าเหล่านี้จะนำไปสู่ความสำเร็จ
Niklas

4
"ทุกอย่างมีลำดับความสำคัญเท่ากัน" - หรือที่เรียกว่า "ทุกอย่างเป็นอันดับ 1" นี่คือตรงไปตรงมาที่สุดพล่าม ทุกอย่างควรได้รับการจัดลำดับความสำคัญอย่างไร้ความปราณีในแง่ของอันตรายต่อธุรกิจ จากนั้นคุณทำงานใน # 1 หากคุณหยุด # 1 ด้วยเหตุผลบางอย่างคุณทำงานใน # 2 และอื่น ๆ หากคุณมีบางคนที่ไม่สามารถทำงานในอันดับที่ 1 ด้วยเหตุผลบางอย่างและพวกเขาก็ลงเอยด้วยการทำงานในอันดับที่ 9 - นั่นคือตกลงหากมีเหตุผลที่ดี ("ฉันรู้สึกเหมือนมันและ cooooooool ของมัน" ไม่ใช่เหตุผลที่ดี) นอกจากนี้ยังตกลงเพื่อจัดลำดับความสำคัญอีกครั้ง การทำบ่อยกว่าสัปดาห์ก็เป็นบ้า
quick_now

ขอบคุณสำหรับภูมิปัญญา ฉันเห็นด้วยอย่างสมบูรณ์ว่าทุกอย่างควรได้รับการจัดลำดับความสำคัญ คู่ของฉันยังระบุด้วยว่าเราไม่ควรมีปัญหาและไม่มีปัญหาในการติดตาม แต่ฉันรู้สึกว่าปัญหาการบันทึกเอกสารนั้นถูกต้องและแม้แต่ผู้นำตลาดยังคอยติดตามปัญหา อีกครั้งทำตรงข้ามของกฎจะทำงาน ...
Niklas

@ 909Niklas คุณน่าจะได้คู่ชีวิตใหม่เพื่อให้ชีวิตในอนาคตของคุณสะดวกสบายยิ่งขึ้น ...
Marcel

+1 สำหรับ: เมื่อเขียน spec ให้พูดเฉพาะสิ่งที่ผลิตภัณฑ์ต้องทำไม่ใช่ว่าจะต้องทำอย่างไร
Marcel

5

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

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

คำถามที่สอง "การสร้างรายวัน" ควรเปลี่ยนเป็นคำถามเกี่ยวกับการรวมระบบอย่างต่อเนื่อง ถ้าคุณไม่สร้างซอฟต์แวร์ที่ใช้เวลาในการสร้าง (ซึ่ง 99.99% ของสถานที่จะไม่ทำ) คำถามควรถามว่า บริษัท ใช้การรวมอย่างต่อเนื่องหรือไม่

การทดสอบ Joel ส่วนใหญ่ไม่ได้ลงวันที่เลย มันยังคงเป็นวิธีที่ดีในการบ่งชี้สภาพแวดล้อมการทำงาน

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