หนึ่งสัปดาห์ที่หยุดทำงานตามโรดแมปแล้วโฟกัสกับการแก้บั๊ก

• องค์กรวิศวกรราว 45 คน หยุดงานตามโรดแมป การออกแบบ และการประชุมเป็นเวลา 1 สัปดาห์ในแต่ละไตรมาส เพื่อจัด ‘สัปดาห์ Fixit’ โดยโฟกัสกับการแก้บั๊กเล็ก ๆ และปัญหาด้านผลิตภาพ
• ใน Fixit ครั้งนี้มีการ แก้บั๊ก 189 รายการ มีผู้เข้าร่วม 40 คน โดยค่ามัธยฐานต่อคนอยู่ที่ 4 รายการ และมากที่สุด 12 รายการ
• ใช้แนวทางอย่าง กฎแก้ให้เสร็จภายใน 2 วัน, ระบบคะแนนและลีดเดอร์บอร์ด, รางวัลเป็นเสื้อยืด เพื่อสร้างแรงจูงใจและยกระดับขวัญกำลังใจของทีม
• การ ใช้เครื่องมือ AI ช่วยให้การสำรวจโค้ดและการเสนอแนวทางแก้ทำได้เร็วขึ้น และลดภาระจากการสลับบริบท
• Fixit ช่วยยกระดับความสมบูรณ์ของผลิตภัณฑ์และเสริมความเหนียวแน่นของทีม พร้อมถูกมองว่าเป็นวัฒนธรรมที่ปลุก ความสนุกของการแก้ปัญหาเล็ก ๆ กลับคืนมา

---

แนวคิดและวิธีดำเนินงานของ Fixit

• Fixit คือสัปดาห์แห่งการแก้บั๊กแบบเข้มข้นที่จัดขึ้นไตรมาสละครั้ง โดย หยุดงานตามโรดแมป การออกแบบ และการประชุมทั้งหมด
  • วิศวกรจะเข้าไปแก้ ข้อผิดพลาดเล็ก ๆ หรือปัจจัยที่บั่นทอนผลิตภาพ ซึ่งทั้งผู้ใช้และนักพัฒนารู้สึกไม่สะดวก
  • ตัวอย่าง: ข้อความแสดงข้อผิดพลาดที่ไม่ชัดเจนมานาน 2 ปี, อาการภาพเพี้ยนเมื่อใช้การเลื่อนและซูมพร้อมกัน, ความล่าช้าของ CI จากการทดสอบที่ช้า
• มีกฎอยู่ 2 ข้อ
  • บั๊กใด ๆ ต้อง ใช้เวลาไม่เกิน 2 วัน
  • งานต้องโฟกัสที่ การปรับปรุงสำหรับผู้ใช้ปลายทาง หรือการเพิ่มผลิตภาพของนักพัฒนา
• มี ระบบคะแนนและลีดเดอร์บอร์ด เพื่อให้เห็นภาพการมีส่วนร่วม และมอบ รางวัลเสื้อยืด ให้หลายหมวด เช่น ‘แก้บั๊กแรก’, ‘แก้บั๊กที่น่าหงุดหงิดที่สุด’

ผลลัพธ์ของ Fixit

• ผลลัพธ์ของ Fixit ครั้งนี้
  • แก้บั๊ก 189 รายการ, ผู้เข้าร่วม 40 คน, ค่ามัธยฐานต่อคน 4 รายการ, สูงสุด 12 รายการ
• กรณีเด่น
  • นำ feature request ของ Perfetto ที่ถูกเปิดไว้ตั้งแต่ปี 2021 มาทำเสร็จภายในวันเดียว ช่วยปรับปรุงประสบการณ์ผู้ใช้
  • แก้ GitHub Action เพื่อลดจำนวนคลิกในการเข้าถึง build สำหรับนักพัฒนา UI
  • จัดทำ SDK เวอร์ชันรวม เพื่อให้รวมเข้ากับโปรเจกต์ได้ง่ายขึ้น โดยใช้เวลาทำราว 1 ชั่วโมง

ผลของ Fixit

• ด้านผลิตภัณฑ์: ความละเอียดและความสมบูรณ์

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

• ด้านบุคคล: ความพึงพอใจจากการลงมือทำ

  • เป็นการได้สัมผัสความสำเร็จแบบฉับไวอีกครั้ง เหมือนช่วงต้นอาชีพที่ “เจอปัญหา → แก้ไข → ปล่อยใช้งาน”
  • ในช่วง Fixit จะโฟกัสที่ ‘จะปรับปรุงอย่างไร’ มากกว่า ‘จะสร้างอะไร’ ทำให้สะสมความสำเร็จได้ในรอบสั้น ๆ

• ด้านทีม: เสริมขวัญกำลังใจและการทำงานร่วมกัน

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

เงื่อนไขสำหรับการทำ Fixit ให้สำเร็จ

• การเตรียมตัวล่วงหน้า

  • ตลอดทั้งปีจะติดแท็กบั๊กว่าเป็น “good fixit candidate” และในสัปดาห์ก่อน Fixit จะจัดหมวดเป็น ขนาดเล็ก/กลาง/ใหญ่ (0.5/1/2 วัน)
  • จากนั้นกำหนด 1/2/4 คะแนน ตามขนาด และจัดทำรายการบั๊กตามลำดับความสำคัญ
  • ขั้นตอนเตรียมนี้คือ หัวใจสำคัญในการป้องกันความสับสนในวันแรก

• กฎจำกัด 2 วัน

  • ในอดีตเคยมีบั๊กหนึ่งรายการซับซ้อนกว่าที่คาดและกินเวลาทั้งสัปดาห์ Fixit
  • หลังจากนั้นจึงเพิ่มหลักการว่า ถ้าเกิน 2 วันให้หยุดและย้ายกลับไป backlog เพื่อ รักษาความรู้สึกสำเร็จอย่างต่อเนื่อง

• ขนาดของผู้เข้าร่วม

  • ตอนเริ่มต้นที่มีเพียง 7 คน แม้จะมีผลงาน แต่ยังขาดการรับรู้ร่วมกันทั้งองค์กร
  • เมื่อมีคนราว 40 คน จะถึงจุดวิกฤตที่เหมาะสม และ ขยายพลังหมู่กับความอินร่วมให้สูงสุด

• Gamification

  • คะแนนออกแบบมาโดย เน้นความสนุกมากกว่าความแม่นยำ (1/2/4 คะแนน)
  • ยอมรับผลงานอย่างกว้างขวาง: ตั้งแต่การแก้ครั้งแรก ไปจนถึงบั๊กที่น่าหงุดหงิดที่สุด
  • แยกออกจากการประเมินผลงาน เพื่อคงแรงจูงใจจากการมีส่วนร่วมล้วน ๆ
  • ด้วยบรรทัดฐานทางสังคมและขนาดทีม จึงแทบ ไม่มีกรณีใช้ระบบในทางที่ผิด

บทบาทของเครื่องมือ AI

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

คำวิจารณ์ต่อ Fixit และการตอบโต้

• “นี่ไม่ได้แปลว่าปกติก็ปล่อยบั๊กไว้เหรอ?”

  • ในระดับหนึ่งก็จริง แต่เป็นการชดเชยความจริงที่ว่า บั๊กจุกจิก (papercut bugs) มักถูกลดลำดับความสำคัญ
  • Fixit คือวิธี กันเวลาไว้อย่างชัดเจน เพื่อแก้ “ปัญหาเล็กแต่สำคัญ”

• “หยุดงานตามโรดแมปแบบนี้ไม่สิ้นเปลืองเหรอ?”

  • แม้การใช้คน 40 คนเป็นเวลา 1 สัปดาห์จะมีต้นทุนสูง แต่ถูกชดเชยด้วย ความสมบูรณ์ของผลิตภัณฑ์ที่ดีขึ้นและความพึงพอใจของผู้ใช้ที่เพิ่มขึ้น
  • ผลด้านผลิตภาพอย่าง การเร่งความเร็วการทดสอบ, การทำให้ข้อความ error ชัดเจนขึ้น, การย่น workflow จะส่งผลต่อเนื่องในระยะยาว

• “นี่เป็นวิธีที่ทำได้เฉพาะบริษัทใหญ่หรือเปล่า?”

  • ทีมเล็กก็ปรับใช้ได้ เช่น ‘Fixit Friday’ หรือ mini Fixit 2 วัน
  • แก่นสำคัญคือ การกันเวลาที่มีสมาธิและได้รับการปกป้อง กับ กิจกรรมปรับปรุงร่วมกัน

คุณค่าแท้จริงของ Fixit

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

[t7vonn]

ทำให้นึกถึงวัฒนธรรม Pit Stop ของ Baemin เลยนะครับ/ค่ะ ได้ยินมาว่าตอนนี้ไม่มีแล้ว

[GN⁺]

ความเห็นจาก Hacker News

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

  • ผมเคยทำงานที่บริษัทซึ่งใช้ MS SQL Server เยอะมาก และมี Heisenbug ที่ทำให้ server cluster หยุดทำงานทุก ๆ สองสามเดือน
    วิเคราะห์ล็อกอยู่หลายปีก็ยังหาสาเหตุไม่เจอ จนกระทั่งพบว่ามันสามารถทำซ้ำได้ 100% ด้วยฐานข้อมูลและชุดคอมมิตในสถานะเฉพาะบางแบบ
    เราเซ็น NDA แล้วสร้าง binary สำหรับการทำซ้ำแบบขั้นต่ำ พร้อมทำอัตโนมัติด้วยสคริปต์ PowerShell จากนั้น MS ก็ออกแพตช์แก้ให้ภายในหนึ่งเดือน
    ภายในดูเหมือนจะเป็น buffer overflow แต่ก็ไม่แน่ชัด
  • ในโปรเจกต์ส่วนใหญ่ที่เต็มไปด้วยบั๊กที่ผมเคยทำงานด้วย ก็มี “กฎ” แบบนี้อยู่โดยนัย
    ถ้าทั้งสัปดาห์มัวแต่แก้บั๊กแล้วเก็บ story point ใน Jira ไม่ได้ ผู้จัดการหลายคนก็มักจะกรูกันมาถามว่าทำไมความเร็วถึงช้าลง
    บทเรียนที่ได้จึงกลายเป็นว่า บั๊กยาก ๆ ควรหลีกเลี่ยง และงานที่ไม่ทำให้ได้แต้มก็ควรเลิกให้ไว
  • ถ้าทำงานฝั่งฮาร์ดแวร์ บั๊กที่ทำซ้ำยาก บางครั้งก็อาจใช้เวลาหลายเดือน
    ไม่มีทางรู้ว่าเป็นปัญหาที่โค้ด คอมไพเลอร์ หรือฮาร์ดแวร์ และ บั๊กเชิงประกอบ ที่เกิดจากหลายปัจจัยพันกันก็มักจะไม่สามารถทำซ้ำแบบแยกเดี่ยวได้เลย
  • ในสถาปัตยกรรมที่ พันกันยุ่งเหยิง แบบเกม มักมีโครงสร้างซับซ้อนประเภทที่ event A ไป trigger B แต่ผลจะต่างกันตามสถานะของ C
    ในกรณีแบบนี้ ถ้าปล่อยให้วิธีแก้เฉพาะหน้าสะสมไปเรื่อย ๆ สุดท้ายการแก้บั๊กให้ถูกต้องจริง ๆ จะกลายเป็น งานรื้อใหญ่
  • มีสองกรณีที่บั๊กแก้ไม่เสร็จ
    1. สาเหตุไม่ชัดเจน ทำให้เวลาส่วนใหญ่หมดไปกับการหา root cause
    2. รู้สาเหตุชัด แต่เป็น ความผิดพลาดเชิงสถาปัตยกรรม ที่จะแก้ต้องยกเครื่องครั้งใหญ่
       อีกอย่าง ใน สภาพแวดล้อมที่ความไว้วางใจต่ำ บางทีแม้แต่บั๊กเล็กน้อยก็ยังแก้ทันทีไม่ได้เพราะขั้นตอนใน Jira

• ตอนทำงานที่ Meta เรามี Fix-it Week ทุกไตรมาส
  ตอนแรกผมคิดว่าฝ่ายผู้นำใส่ใจเรื่องคุณภาพ แต่ความจริงมันคือ ช่วงเวลาที่ได้รับใบอนุญาตให้สะสมหนี้ทางเทคนิค
  พอถึงสัปดาห์ที่พยายามจะไปแก้บั๊ก ก็แทบแก้อะไรไม่ได้แล้วเพราะหนี้ที่กองสะสมไว้ก่อนหน้า

  • มันทำให้นึกถึงนโยบายของ id Software — “เห็นบั๊กแล้วให้แก้ทันที”
    ไม่อย่างนั้นโค้ดใหม่จะไปกองทับบนบั๊กเดิมจนกลายเป็น ฐานรากที่ไม่มั่นคง
    วิดีโอบรรยายของ John Romero ก็เน้นปรัชญาเดียวกัน
  • Fix-it Week ที่ Meta ในทางปฏิบัติจริง ๆ คือ สัปดาห์รีแฟกเตอร์
    นักพัฒนาจะมาเคลียร์ TODO ที่เคยทิ้งไว้และเพิ่ม LOC กัน บางคนถึงขั้นเขียนโค้ดผิดไว้ตั้งใจเพื่อจะมา “แก้” ทีหลัง เป็น ลูกเล่นเพิ่มจำนวน diff
  • อย่างที่ต้นฉบับบอก Fix-it Week คือสัปดาห์ที่เน้น บั๊กเล็ก ๆ หรือการปรับปรุงประสบการณ์นักพัฒนา
    กล่าวคือเป็นเวลาสำหรับจัดการปัญหาที่ไม่เร่งด่วนแต่ชวนรำคาญ
  • สัปดาห์แบบนี้กลับกลายเป็น ข้ออ้างทางใจ ว่า “ตอนนี้ยังไม่ต้องแก้ก็ได้ ไว้ทำตอน Fix-it Week”
    สิ่งที่สำคัญกว่าคือให้ฝ่ายผู้นำอธิบาย ลำดับความสำคัญทางธุรกิจ อย่างตรงไปตรงมา และแสดงให้ชัดว่าบั๊กนั้นกระทบผู้ใช้อย่างไร
  • ถ้าสนใจคุณภาพจริง ๆ วิธีที่เป็นจริงที่สุดคือ ผสานการแก้บั๊กเข้าไปในงานพัฒนาฟีเจอร์ ตามธรรมชาติ

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

  • แพตเทิร์นแบบนี้คือ อาการคลาสสิกขององค์กรที่กำลังพัง
    การสื่อสารขาดสะบั้น และผู้นำก็ วิ่งวุ่นสั่งการเหมือนไก่ไร้หัว
    นักพัฒนาถูกลดบทบาทให้เป็นหน่วยดับเพลิงของทุกปัญหา และสุดท้ายทางออกเดียวคือหนีออกมา
  • นี่คือ ความล้มเหลวของผู้นำ อย่างชัดเจน
    ยิ่งช้าลงเท่าไร ผู้นำก็ยิ่งตื่นตระหนกมากขึ้น แล้วก็โยกย้ายโปรเจกต์แบบสะเปะสะปะจนสร้าง ความสับสนและวัฒนธรรมเป็นพิษ
  • ถ้าอยากหลีกเลี่ยงสถานการณ์แบบนี้ ก็ต้องมีทักษะในการ บริหารความคาดหวัง แทนที่จะพยายามทำให้ลูกค้าพอใจทุกอย่างเสมอ
  • อย่างไรก็ตาม ถ้าบริษัทยังอยู่ในช่วงหา PMF (Product-Market Fit) การทุ่มเวลาไปกับงานวิศวกรรมที่สมบูรณ์แบบอาจไม่มีประสิทธิภาพก็ได้
  • สรุปแล้ว ปัญหาไม่ได้อยู่ที่ตัวบุคคล แต่คือ วัฒนธรรมองค์กรที่เป็นพิษ คำตอบคือออกมาให้เร็วที่สุดเท่าที่ทำได้

• ผมทำงานด้วยแนวคิด “แก้บั๊กก่อน” มาโดยตลอด
  ถ้าฟีเจอร์เดิมยังทำงานไม่ถูกต้อง ผมจะไม่สร้างฟีเจอร์ใหม่
  วิธีนี้ช่วยให้รักษา codebase ที่ปลอดบั๊ก ได้ และยังเพิ่มประสิทธิภาพของทีมด้วย

  • แต่ยิ่งทีมใหญ่ขึ้น ก็ยิ่งมีแนวโน้มจะให้ความสำคัญกับ การพัฒนาฟีเจอร์ใหม่ มากกว่าบั๊ก
  • ผมมักถูกถามบ่อยว่าทำวัฒนธรรมแบบนี้ได้จากที่ไหน
    โดยเฉพาะฝั่งฟรอนต์เอนด์ที่มีปัญหาจากสภาพแวดล้อมหลากหลาย ทำให้การมี สถานะไร้บั๊กโดยสมบูรณ์ แทบเป็นไปไม่ได้
    อีกทั้งคำว่า “บั๊ก” เองก็คลุมเครือ จนบางครั้งฟีเจอร์ที่ผู้จัดการอยากได้ก็ถูกจัดเป็นบั๊ก
  • บั๊กเองก็มี ลำดับความสำคัญ
    ตัวอย่างเช่น error บนหน้า API ที่แทบไม่มีใครใช้ อาจสำคัญน้อยกว่าฟีเจอร์ใหม่
  • ระบบที่มีผู้ใช้จำนวนมากมักมีบั๊กอยู่เป็นพันรายการ
    ส่วนใหญ่เป็นปัญหาเล็กน้อย ดังนั้นฝ่ายผู้นำจึงมักเลือก ฟีเจอร์ใหม่ มากกว่า
  • ในความเป็นจริง ไม่มี codebase ที่บั๊กเป็นศูนย์ อยู่จริง การเชื่อว่าไม่มีบั๊กเป็นแค่การมองไม่เห็นเท่านั้น

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

  • แต่ก็มีคนเห็นด้วยว่าใน legacy codebase ที่มีอายุ 15 ปี การใช้หลักการนี้ทำได้ยาก
  • ผมเคยเขียนเรื่องนี้ไว้ด้วย — Fix Bugs or Add New Features

• ระบบอย่าง Fix-it Week กลับยิ่ง ส่งเสริมการเลื่อนการแก้บั๊ก
  เพราะมีข้ออ้างว่า “ไว้ค่อยทำตอน Fix-it Week”
  ทางที่ดีกว่าคือใส่ เวลาสำหรับงานบำรุงรักษา ไว้อย่างชัดเจนในแผนรายไตรมาสหรือรายสปรินต์
  แบบนี้นักพัฒนาจะมีเหตุผลรองรับในการแก้บั๊กทันที และช่วยสร้าง วัฒนธรรมการปรับปรุงอย่างต่อเนื่อง
  ถ้าจะมี Fix-it Week จริง ๆ ก็ควรทำให้คล้ายมินิแฮ็กกาธอนที่รวม การปรับปรุงเล็ก ๆ หรือ POC ไว้ด้วย

• บริษัทเก่าของผมวนอยู่กับวงจรเดิมตลอด

  1. ทุ่มทั้งหมดไปกับการพัฒนาฟีเจอร์ → 2) เกิด incident ใหญ่กับลูกค้ารายสำคัญ → 3) หยุดการพัฒนาทั้งหมดแล้วเข้าสู่ สัปดาห์แก้บั๊ก
     แพตเทิร์นแบบนี้คือ สัญญาณว่าวัฒนธรรมองค์กรผิดเพี้ยน ถ้าไม่กันเวลาไว้สำหรับแก้บั๊กในเวลาปกติ มันจะไม่มีวันเปลี่ยน

• ทำให้นึกถึง Joel Test ที่ Joel Spolsky เคยเสนอไว้
  ในข้อที่ห้า เขาถามว่า “คุณแก้บั๊กก่อนเขียนโค้ดใหม่หรือไม่?”
  ผ่านมา 25 ปีแล้ว มันก็ยังเป็นเกณฑ์ที่ใช้ได้อยู่
  ลิงก์ต้นฉบับ

• ผมอยู่ฝ่ายที่มองว่าไม่ควรให้ คะแนนหรือประเมินขนาด กับบั๊ก
  ถ้าจำเป็นต้องมีคะแนนจริง ๆ ก็ให้ทุกอันเป็น 2 ไปเลย เพราะโดยเฉลี่ยแล้วก็ใกล้เคียงความจริง
  การแก้บั๊กควรทำแบบ Kanban คือเรียงตามความสำคัญแล้วทำให้เสร็จภายในเวลาที่มี

• ผมเป็นคนเขียนบทความเอง ดีใจที่มีการถกเถียงกันอย่างคึกคัก

  1. เพราะคาดเดาความซับซ้อนของบั๊กได้ยาก ผมจึงแนะนำว่าให้สืบสวนอยู่ไม่กี่ชั่วโมงก่อน และถ้าพบว่า ขอบเขตใหญ่ขึ้น ก็ควรแยกไปเป็นอีก issue หนึ่ง
  2. เราใช้คำว่า “บั๊ก” เป็นคำภายในองค์กรที่ครอบคลุมไม่เฉพาะข้อผิดพลาดแบบดั้งเดิม แต่รวมถึง คำขอปรับปรุงฟีเจอร์ ด้วย
  3. มีความเสี่ยงที่ Fix-it Week จะกลายเป็น “ไว้ค่อยทำตอนนั้น” แต่ของเราใช้สำหรับ บั๊กเล็ก ๆ เท่านั้น
     มันไม่ใช่สิ่งทดแทนสำหรับงานสุขอนามัยทางเทคนิคหรือการแก้ปัญหาใหญ่
  • มีคนชมว่าบทความน่าสนใจ และถามต่อว่ามี regression หรือข้อผิดพลาดใหม่ เกิดขึ้นจากการแก้บั๊กมากน้อยแค่ไหน