การประชุมที่เกิดจากการ deploy ที่ช้า (2015)

 (tidyfirst.substack.com)
4 คะแนน โดย GN⁺ 2024-12-23 | 2 ความคิดเห็น | แชร์ทาง WhatsApp

การ deploy ช้าเป็นต้นเหตุให้เกิดการประชุม

  • การออกแบบซอฟต์แวร์คือการฝึกฝนความสัมพันธ์ระหว่างคน และทักษะทางเทคนิคที่ใช้ในการพัฒนาซอฟต์แวร์ก็เป็นเช่นเดียวกัน
  • ความไม่พอใจของวิศวกรที่ว่า “มีการประชุมมากเกินไปจนไม่สามารถ deploy โค้ดได้” อาจเกิดจากข้อจำกัดด้านขีดความสามารถในการ deploy
  • Chuck Rossi สังเกตจาก Facebook ว่าจำนวนการเปลี่ยนแปลงที่สามารถจัดการได้ต่อการ deploy หนึ่งครั้งมีการกำหนดไว้แน่นอน และหากต้องการการเปลี่ยนแปลงมากขึ้นก็ต้องเพิ่มจำนวนการ deploy
  • Facebook เพิ่มความเร็วในการ deploy จากรายสัปดาห์เป็นรายวันเป็นวันละสามครั้งในช่วงห้าปีที่ผ่านมา และรอบการ deploy ของแอปมือถือก็ลดจาก 6 สัปดาห์เป็น 4 สัปดาห์ และ 2 สัปดาห์
  • “การเปลี่ยนแปลงต่อการ deploy” เป็นตัวชี้วัดที่ไม่ยืดหยุ่น มันสามารถปรับปรุงได้แต่ต้องใช้เวลา หากการเปลี่ยนแปลงเกินเพดานปัจจุบัน จะต้องลดจำนวนการเปลี่ยนแปลงลง
  • เมื่อเพิ่มภาระงานทางองค์กร จะเกิดลูปตอบสนองเชิงบวก: ปริมาณงานลดลง -> ความกดดันเพิ่ม -> ความผิดพลาดเพิ่ม -> การเปลี่ยนแปลงต่อการ deploy ลดลง -> ภาระงานทางองค์กรเพิ่ม -> ปริมาณงานลดลง
  • หากต้องการรองรับการเปลี่ยนแปลงมากขึ้น ต้องเพิ่มความจุการ deploy ทั้งนี้ได้โดยการลดรอบการ deploy หรือเพิ่มการเปลี่ยนแปลงต่อการ deploy
  • การพยายามลดภาระงานทางองค์กรอาจส่งผลให้มีการประชุมมากขึ้น ซึ่งช่วยจำกัดการพยายาม deploy โค้ดเกินขีดจำกัด

Software Design: Tidy First?

  • การออกแบบซอฟต์แวร์คือการฝึกฝนความสัมพันธ์ระหว่างคน การพัฒนาทักษะทางเทคนิคแบบอื่นๆ ก็เป็นแนวทางหนึ่งในการปรับความสัมพันธ์เหล่านี้

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
roxie 2024-12-24

ความคิดเห็นนี้น่าสนใจมาก
 
GN⁺ 2024-12-23
ความคิดเห็น Hacker News

  • การลดความเสี่ยงในการปรับใช้ด้วยการปรับปรุงการทดสอบและลักษณะทางองค์กรเป็นสิ่งสำคัญ แต่ไม่ใช่วิธีเดียว

    • การลดจำนวนการเปลี่ยนแปลงต่อการปรับใช้หนึ่งครั้งให้ค่อนข้างเป็นผลมากกว่า
    • การปรับใช้การเปลี่ยนแปลงเล็ก ๆ อย่างสม่ำเสมอช่วยส่งมอบคุณค่าได้เร็วขึ้นและช่วยรับมือกับความล้มเหลวขนาดเล็กได้
    • เมื่อใช้ร่วมกับการปรับใช้แบบ canary และการปล่อยแบบค่อยเป็นค่อยไป การปรับใช้จึงไม่เป็นความเสี่ยงที่ใหญ่แล้ว
    • การวิจัยของ DORA สนับสนุนแนวทางนี้ พร้อมกับ Accelerate, The Phoenix Project และ The Goal

  • พยายามอธิบายแนวคิดที่เรียกว่า "software literacy"

    • หมายถึงความสามารถขององค์กรในการดำเนินงานด้วยโค้ด
    • หากผู้ตัดสินใจทุกคนไม่สามารถมุ่งเน้นที่โค้ดได้ แสดงว่าบริษัทขาด software literacy
    • องค์กรควรดำเนินการได้ด้วยแนวคิดใหม่ ๆ

  • เมื่อการทดสอบใช้เวลานานใน CI pipeline จึงตัดสินใจเน้นการฟื้นตัว

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

  • องค์กรอาจขัดขวางการปรับปรุงการปรับใช้ได้

    • การต่อสู้กับระบบราชการแทบเป็นไปไม่ได้ในองค์กรส่วนใหญ่
    • การปรับใช้อย่างช้าเป็นปัญหา แต่ไม่ใช่ปัญหาเดียว

  • การเพิ่มจำนวนการทดสอบเกิดจากความกลัวการเปลี่ยนแปลงขนาดใหญ่

    • แนวโน้มที่การประชุมจะกลายเป็นเป้าหมาย
    • ต้องการคำแนะนำในการนำผู้บริหารที่ไม่ใช่ฝ่ายเทคนิคและการขับเคลื่อนการเปลี่ยนแปลงเชิงเทคนิค

  • คำถามว่า CloudFormation ทำไมจึงช้า

  • ไมโครเซอร์วิสทำให้สามารถขยายความถี่การปรับใช้แบบแนวนอนได้

  • ประสิทธิภาพซอฟต์แวร์ หรือที่เรียกว่าประสิทธิภาพของมนุษย์นั้นสำคัญ

    • จำเป็นต้องมีการอัตโนมัติการทดสอบอย่างรวดเร็วเพื่อให้เกิดรอบการทำซ้ำเร็วขึ้นและลดความเสี่ยง

  • การปรับใช้เร็วก่อให้เกิดการประชุมตอบสนองเหตุการณ์