The Hawthorne Effect (ปรากฏการณ์ Hawthorne)

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

วิธีหนึ่งในการแก้ปัญหานี้คือการพูดคุยกับทีมเกี่ยวกับความแตกต่างที่การใช้เช็คลิสต์สามารถสร้างได้ และให้พวกเขาอ่านหนังสือ The Checklist Manifesto โดย Atul Gawande ทำให้แน่ใจว่าสมาชิกในทีมทุกคนเข้าใจเหตุผลเบื้องหลังของแต่ละเช็คลิสต์ ลองให้พวกเขาร่วมกันตัดสินใจว่าขั้นตอนใด ควรอยู่หรือไม่ควรอยู่ในเช็คลิสต์ การสร้างความรู้สึกเป็นเจ้าของก็ช่วยได้เช่นกัน

เมื่อวิธีอื่นๆ ไม่ได้ผล ยังมี Hawthorne effect คือแนวโน้มที่คนที่รู้ว่าตัวเองกำลังถูกสังเกตหรือติดตามจะเปลี่ยนพฤติกรรม โดยทั่วไปจะเปลี่ยนไปทำสิ่งที่ถูกต้อง ผลกระทบนี้ไม่จำเป็นต้องมีการติดตามจริงๆ มากเท่ากับการรับรู้ว่าถูกติดตาม ตัวอย่างเช่น นายจ้างหลายคนติดตั้งกล้องที่ไม่ทำงานจริง ในพื้นที่ที่มองเห็นได้ชัดเจน ในขณะที่บางคนติดตั้งซอฟต์แวร์ตรวจสอบเว็บไซต์ที่แทบไม่เคยตรวจสอบเลย (มีรายงานเหล่านั้นกี่ฉบับที่ผู้จัดการดูจริงๆ?)

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

Developer Code-Completion Checklist (เช็คลิสต์การทำโค้ดให้เสร็จสมบูรณ์ของนักพัฒนา)

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

นี่คือตัวอย่างสิ่งที่ควรใส่ในเช็คลิสต์การทำโค้ดให้เสร็จสมบูรณ์ของนักพัฒนา:

  • มาตรฐานการเขียนโค้ดและการจัดรูปแบบที่ไม่ได้รวมอยู่ในเครื่องมืออัตโนมัติ

  • รายการที่มักถูกมองข้าม (เช่น exception ที่ถูกกลืนหายไป)

  • มาตรฐานเฉพาะโครงการ

  • คำแนะนำหรือขั้นตอนพิเศษของทีม

Figure 24-10 แสดงตัวอย่างเช็คลิสต์การทำโค้ดให้เสร็จสมบูรณ์ของนักพัฒนา มีงานที่ชัดเจนบางอย่างในนี้ เช่น "รันการทำความสะอาดโค้ดและจัดรูปแบบโค้ด" และ "ตรวจสอบให้แน่ใจว่าไม่มี exception ที่ถูกกลืนหายไป" นักพัฒนาที่รีบร้อนลืมรันการทำความสะอาดโค้ดและจัดรูปแบบจาก IDE บ่อยแค่ไหน? บ่อยมากทีเดียว ใน The Checklist Manifesto Gawande พบปรากฏการณ์เดียวกันนี้ในเรื่องขั้นตอนการผ่าตัด งานที่ชัดเจนที่สุดมักเป็นงานที่ถูกมองข้ามบ่อยที่สุด

Code-Completion Checklist

Figure 24-10. ตัวอย่างเช็คลิสต์การทำโค้ดให้เสร็จสมบูรณ์ของนักพัฒนา

สถาปนิกควรตรวจสอบเช็คลิสต์อยู่เสมอเพื่อดูว่ามีรายการใดที่สามารถ automate หรือเขียนเป็นปลั๊กอินสำหรับตัวตรวจสอบความถูกต้องของโค้ดได้บ้าง แม้ว่างานเฉพาะโครงการในเช็คลิสต์ (เช่น การรัน custom validator การตรวจสอบว่า audit log ถูกเขียนแล้ว การเรียกเมธอด setFailure() และการใส่ annotation @ServiceEntrypoint ) จะดีถ้ามีอยู่ในเช็คลิสต์ แต่บางส่วนก็สามารถ automate ได้ ตัวอย่างเช่น แม้การตรวจสอบอัตโนมัติอาจทำไม่ได้สำหรับ "ใส่ @ServiceEntrypoint บนคลาส service API" แต่มันสามารถทำได้สำหรับ "ตรวจสอบว่ามีแต่ public method เท่านั้นที่เรียก setFailure() " ซึ่งเป็นการตรวจสอบที่ตรงไปตรงมาและสามารถ automate ได้ด้วยเครื่องมือ code-crawling ใดๆ การมองหาส่วนที่สามารถ automate ได้ช่วยลดขนาดของเช็คลิสต์และเพิ่มอัตราส่วนสัญญาณต่อสัญญาณรบกวน

Unit and Functional Testing Checklist (เช็คลิสต์การทดสอบยูนิตและฟังก์ชัน)

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

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

นี่คือตัวอย่างรายการที่พบได้ในเช็คลิสต์การทดสอบยูนิตและฟังก์ชันทั่วไป:

  • อักขระพิเศษในฟิลด์ข้อความและตัวเลข

  • ค่าต่ำสุดและสูงสุดของช่วงค่า

  • เทสต์เคสที่ผิดปกติและสุดขั้ว

  • ฟิลด์ที่ขาดหายไป

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

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

Software-Release Checklist (เช็คลิสต์การปล่อยซอฟต์แวร์)

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

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

เช็คลิสต์การปล่อยซอฟต์แวร์โดยทั่วไปประกอบด้วย:

  • การเปลี่ยนแปลงคอนฟิกในเซิร์ฟเวอร์หรือเซิร์ฟเวอร์คอนฟิกภายนอก

  • ไลบรารีจากบุคคลที่สามที่เพิ่มเข้ามาในโครงการ (JAR, DLL ฯลฯ)

  • การอัปเดตฐานข้อมูลและสคริปต์ migration ฐานข้อมูลที่เกี่ยวข้อง

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