การพัฒนาแบบ Follow-the-Sun: Hamburg + Ho Chi Minh City = วิศวกรรมตลอด 24 ชั่วโมง

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

ความท้าทายคือทีมส่วนใหญ่ที่อ้างว่าใช้โมเดลนี้กลับไม่ได้ปฏิบัติตามจริง นี่คือสิ่งที่โมเดลนี้ต้องการอย่างแท้จริง และวิธีที่ Gradion ดำเนินการระหว่าง Hamburg กับ Ho Chi Minh City

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

Follow-the-Sun (FTS) ตามคำพูดของ Carmel, Espinosa และ Dubinsky ซึ่งเป็นนักวิจัยผู้วางรากฐานทางวิชาการสำหรับโมเดลนี้ คือรูปแบบกระบวนการทำงานด้านความรู้ระดับโลกที่ออกแบบมาเพื่อลดระยะเวลาออกสู่ตลาด งานจะถูกส่งต่อระหว่างทีมที่กระจายตามภูมิศาสตร์เมื่อแต่ละไซต์สิ้นสุดวันทำงาน ทีมที่รับงานจะดำเนินการต่อทันที การพัฒนาจึงดำเนินไปอย่างต่อเนื่อง

ด้วยสองไซต์ จะขยายชั่วโมงที่มีประสิทธิผลเป็น 16 ชั่วโมงต่อวัน ด้วยสามไซต์จะได้ 24 ชั่วโมง IBM บุกเบิกแนวทางนี้ในช่วงกลางทศวรรษ 1990 การพยายามครั้งแรกล้มเหลว ไม่ใช่เพราะแนวคิดผิด แต่เพราะการส่งมอบงานประจำวันไม่ได้ดำเนินการอย่างสม่ำเสมอ

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

เหตุใดจึงเลือก Hamburg กับ Ho Chi Minh City?

Hamburg ใช้ CET (UTC+1) ในฤดูหนาว และ CEST (UTC+2) ในฤดูร้อน Ho Chi Minh City ใช้ ICT (UTC+7) ตลอดทั้งปี ส่วนต่างเวลาคือ 5 ชั่วโมงในฤดูร้อน และ 6 ชั่วโมงในฤดูหนาว

Gradion ยังดำเนินศูนย์วิศวกรรมใน Cairo อีกด้วย อียิปต์ใช้ EET (UTC+2) ตลอดทั้งปี โดยยกเลิกการใช้เวลาออมแสงในปี 2011 ทำให้ Cairo อยู่ในแถบเขตเวลาเดียวกับ Hamburg ได้แก่ เวลาเดียวกันในฤดูร้อน และเร็วกว่าหนึ่งชั่วโมงในฤดูหนาว

ในแง่ของ FTS นั้น Hamburg และ Cairo ร่วมกันเป็นจุดยึดฝั่งตะวันตก ไม่ใช่จุดส่งต่องานที่เป็นอิสระสองจุด ทั้งสองไซต์ใช้ช่วงเวลาเช้าของยุโรปและ MENA ร่วมกัน เสริมความสามารถด้านวิศวกรรมฝั่งตะวันตก และขยายการครอบคลุมตลาดของ Gradion เข้าสู่ภูมิภาค MENA งานจะถูกส่งไปทางตะวันออกสู่ HCMC เมื่อยุโรปและ MENA ปิดทำการ และส่งกลับมายังทีมฝั่งตะวันตกในเช้าวันถัดไป

การดำเนินการนี้สร้างช่วงเวลาทับซ้อนตามธรรมชาติ Hamburg และ Cairo เริ่มงานเวลา 09:00 ตามเวลาท้องถิ่น ขณะที่ HCMC อยู่ที่เวลา 14:00 ICT ซึ่งอยู่ในช่วงบ่าย กำลังทำงานเต็มที่ การประสานงานแบบมีโครงสร้างตั้งแต่ 09:00 ถึง 11:00 CET ช่วยให้ทั้งสองฝ่ายมีบริบทร่วมกัน จากนั้นทีมฝั่งตะวันตกจะส่งมอบงาน และ HCMC จะดำเนินงานต่อไปจนถึงค่ำ

เมื่อ HCMC ปิดงานเวลา 18:00 ICT Hamburg อยู่ที่เวลา 12:00-13:00 CET ของวันถัดไป งานที่เสร็จสิ้นแล้วรออยู่ การทบทวนเริ่มต้น วงจรดำเนินต่อไป

สิบหกชั่วโมงการทำงานด้านวิศวกรรมที่มีประสิทธิผล ไม่มีใครต้องทำงานนอกเวลาปกติ ไม่ต้องพึ่งความพยายามพิเศษจากใคร

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

อะไรทำให้ระบบนี้ทำงานได้จริงในทางปฏิบัติ?

Kroll et al. (2013) ได้ทบทวนแนวปฏิบัติที่ดีที่สุด 36 ข้อในการดำเนินงาน Follow-the-Sun ข้อค้นพบของพวกเขาคือ คุณภาพของการส่งมอบงานเป็นปัจจัยที่สำคัญที่สุดเพียงหนึ่งเดียว การส่งบริบทที่ไม่ดีคือจุดที่ FTS พังทลาย ไม่ใช่ช่องว่างของเขตเวลาหรือความแตกต่างทางวัฒนธรรม

ในทางปฏิบัติ กระบวนการทำงาน FTS ที่ใช้งานได้จริงต้องการสี่สิ่ง ได้แก่

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

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

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

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

Follow-the-Sun ไม่ใช่อะไร

FTS มักถูกอ้างสิทธิ์บ่อยครั้งแต่แทบไม่ได้ปฏิบัติจริง Treinen และ Miller-Frost (2006) ในกรณีศึกษาของ IBM Systems Journal ได้บันทึกทั้งการดำเนินการ FTS ที่สำเร็จและล้มเหลว ความล้มเหลวที่พบบ่อยที่สุดคือทีมทำงานแบบคู่ขนานแทนที่จะเป็นลำดับ ทั้งสองไซต์ทำงานพร้อมกัน แต่ไม่มีไซต์ใดที่สร้างต่อจากผลงานของอีกไซต์ ผลลัพธ์คือการทำงานซ้ำซ้อน ความขัดแย้งในการรวมโค้ด และค่าใช้จ่ายในการประสานงานที่ลบล้างข้อได้เปรียบของเขตเวลาทั้งหมด

ผู้ให้บริการที่อธิบายโมเดลของตนว่าเป็น Follow-the-Sun แต่ไม่สามารถอธิบายกระบวนการส่งมอบงานได้ ไม่ได้กำลังดำเนินการ FTS แต่กำลังดำเนินทีมกระจายตัวที่มีการนำเสนอตำแหน่งตลาดที่ขัดเกลามากขึ้นเท่านั้น

ความแตกต่างนี้ก่อให้เกิดผลลัพธ์ที่ต่างกัน การพัฒนาแบบกระจายขนานกันช่วยขยายกำลังคน Follow-the-Sun ช่วยขยายความเร็ว อย่างแรกเพิ่มวิศวกร อย่างหลังบีบอัดปฏิทิน

โมเดลของ Gradion ในทางปฏิบัติ

การตั้งค่าของ Gradion ถูกออกแบบโดยยึดหลัก FTS ตั้งแต่ต้น ไม่ใช่การปรับแก้โครงสร้างที่มีอยู่เดิมภายหลัง

ทีม Hamburg ทำหน้าที่ยึดความสัมพันธ์กับลูกค้า การตัดสินใจด้านสถาปัตยกรรม และการเป็นเจ้าของสปรินต์ Cairo เสริมความแข็งแกร่งให้กับจุดยึดฝั่งตะวันตก ขยายความลึกด้านวิศวกรรมและการครอบคลุมตลาด MENA ภายในแถบเขตเวลาเดียวกัน HCMC รับปริมาณงานวิศวกรรมหลักในฐานะพันธมิตรการส่งมอบเต็มรูปแบบ ไม่ใช่แหล่งทรัพยากร

การส่งมอบงานถูกบันทึกเป็นลายลักษณ์อักษร ช่วงเวลาทับซ้อนได้รับการปกป้อง การสื่อสารแบบ Async เป็นค่าเริ่มต้น ไม่ใช่ทางเลือกสำรอง

สำหรับลูกค้า นั่นหมายความว่าปัญหาที่แก้ไขเวลา 17:00 CET ไม่ต้องรอจนถึงเวลา 09:00 เช้าวันรุ่งขึ้น แต่จะถูกรับไปดำเนินการในตอนเย็นที่ HCMC ผลลัพธ์พร้อมให้ Hamburg และ Cairo ตรวจสอบเมื่อเปิดทำการ

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

คำถามที่ควรถามผู้ให้บริการ Follow-the-Sun

หากคุณกำลังประเมินว่าผู้ให้บริการดำเนินงานบน FTS อย่างแท้จริงหรือไม่ ให้ถามสามคำถาม ดังนี้

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

ผู้ให้บริการที่ตอบทั้งสามข้อได้อย่างเฉพาะเจาะจงคือผู้ที่ดำเนินโมเดลนี้จริง ส่วนผู้ให้บริการที่อธิบายเพียงการกระจายเขตเวลาโดยไม่บรรยายกระบวนการส่งมอบ ไม่ใช่ผู้ดำเนินงาน FTS

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

แหล่งอ้างอิง

Carmel, Espinosa & Dubinsky (2010), Follow-the-Sun Software Development, Journal of Management Information Systems
Treinen & Miller-Frost (2006), IBM Systems Journal — successful and failed FTS case studies
Kroll et al. (2013), systematic literature review — 36 FTS best practices identified
Wikipedia — Follow-the-sun (citing Carmel, Dubinsky & Espinosa, 2009, Hawaii International Conference on System Sciences)
Timezone offsets: CET UTC+1, CEST UTC+2, EET UTC+2 year-round (Egypt abolished DST 2011), ICT UTC+7