การพัฒนาซอฟต์แวร์แบบ Follow-the-Sun ทำงานอย่างไรจริง ๆ ในระดับองค์กร

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

โมเดล Follow-the-Sun ทำงานอย่างไร

ในรูปแบบ follow-the-sun ทั่วไป ทีมวิศวกรรมจะกระจายอยู่ในสองหรือสามโซนภูมิศาสตร์ ซึ่งรวมกันครอบคลุมชั่วโมงทำงานที่มีประสิทธิผลตั้งแต่สิบหกถึงยี่สิบสองชั่วโมง การจัดวางที่พบบ่อยในภูมิภาค APAC คือทีมในสิงคโปร์หรือเวียดนาม ร่วมกับทีมในยุโรปหรือเยอรมนี และอาจมีทีมที่สามในทวีปอเมริกาเพิ่มเติม

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

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

สิ่งที่ Follow-the-Sun ต้องการในเชิงปฏิบัติการ

มาตรฐานการจัดทำเอกสาร

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

วินัยด้านเอกสารคือจุดที่ล้มเหลวบ่อยที่สุดในการนำ follow-the-sun ไปใช้ ทีมที่พึ่งพาความรู้ที่ถ่ายทอดกันแบบปากต่อปากหรือการส่งต่อบริบทด้วยวาจา ไม่สามารถรักษาโมเดลนี้ไว้ได้ในระดับองค์กร

ขั้นตอนการส่งต่องาน

ขั้นตอนการส่งต่องานกำหนดสิ่งที่ต้องทำให้เสร็จก่อนที่ทีมจะสิ้นสุดวันทำงาน ขั้นตอนมาตรฐานประกอบด้วย

• อัปเดตสถานะของทุกงานที่กำลังดำเนินอยู่ (เสร็จแล้ว ติดขัด อยู่ระหว่างรีวิว)
• บันทึกคำถามที่ยังติดขัดและทำเครื่องหมายให้ทีมที่รับช่วงต่อ
• ยืนยันสถานะของ branch และ pull request (ไม่มีงานที่ commit ค้างไว้ครึ่งเดียว)
• ตรวจสอบสภาพแวดล้อม ไม่ทิ้ง build ที่เสียไว้ให้ทีมถัดไป
• บันทึกความสำคัญสำหรับสองชั่วโมงแรกของทีมที่รับช่วงต่อ

ขั้นตอนการส่งต่องานควรถูกบังคับใช้ผ่านเครื่องมือเท่าที่ทำได้ รายการตรวจสอบในเครื่องมือจัดการโครงการ รายงานสถานะ CI/CD อัตโนมัติ และวิดีโอสรุปแบบไม่พร้อมกันที่มีโครงสร้างชัดเจน ล้วนช่วยลดความเสี่ยงของการสูญเสียบริบทในจุดเปลี่ยนผ่าน

โครงสร้างพื้นฐานการสื่อสารแบบไม่พร้อมกัน

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

ความสอดคล้องของเครื่องมือ

ทุกทีมต้องใช้เครื่องมือเดียวกันสำหรับการเขียนโค้ด การติดตามโครงการ และการสื่อสาร เครื่องมือที่แตกต่างกันจะสร้างแรงเสียดทานในการแปลความหมายเมื่อส่งต่องาน ในระดับองค์กร สิ่งนี้รวมถึงไปป์ไลน์ CI/CD ที่เป็นมาตรฐานเดียวกัน แดชบอร์ด observability ที่ใช้ร่วมกัน และกฎการป้องกัน branch ที่สอดคล้องกันในทุก repository

อะไรทำให้ Follow-the-Sun ได้ผลในระดับองค์กร

องค์กรที่ดำเนินการพัฒนาแบบ follow-the-sun ได้สำเร็จมีลักษณะการปฏิบัติงานร่วมกันสามประการ ประการแรก พวกเขาถือว่าเอกสารเป็นผลงานส่งมอบ ไม่ใช่ภาระงานเสริมที่เลือกทำก็ได้ ประการที่สอง พวกเขามีหัวหน้าฝ่ายเทคนิคหรือเจ้าของสถาปัตยกรรมเพียงคนเดียวที่ครอบคลุมทุกเขตเวลาและพร้อมรับมือกับปัญหาที่ต้องยกระดับข้ามกะ ประการที่สาม พวกเขาจัดการทบทวนงานอย่างเป็นระบบเกี่ยวกับคุณภาพของการส่งต่องาน ไม่ใช่แค่การส่งมอบฟีเจอร์เท่านั้น

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

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

อะไรทำให้ Follow-the-Sun ล้มเหลว

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

ความล้มเหลวที่พบบ่อยประการที่สองคือการพึ่งพาการทับซ้อนของเขตเวลา หากทีมถูกออกแบบให้ทำงานต่อเนื่องกัน แต่การตัดสินใจสำคัญกลับต้องให้ทั้งสองทีมออนไลน์พร้อมกัน โมเดลนี้จะล้มเหลว ทีมวิศวกรรมที่กระจายตัวและดำเนินงานตามหลัก follow-the-sun ควรสามารถตัดสินใจส่วนใหญ่ได้ด้วยตัวเองภายในกะของตน

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

คำถามที่พบบ่อย

การพัฒนาซอฟต์แวร์แบบ Follow-the-Sun คืออะไร

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

ต้องใช้กี่เขตเวลาเพื่อให้ Follow-the-Sun ได้ผล

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

ความเสี่ยงที่ใหญ่ที่สุดในการตั้งค่า Follow-the-Sun คืออะไร

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

การพัฒนาแบบ Follow-the-Sun เหมาะสมกับอุตสาหกรรมที่มีการกำกับดูแลเข้มงวดหรือไม่

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