Phát triển phần mềm Follow-the-Sun: Hamburg + Ho Chi Minh City = Kỹ thuật liên tục suốt ngày đêm

Một sprint không nhất thiết phải dừng lại khi đội ngũ châu Âu của bạn kết thúc ngày làm việc. Phát triển phần mềm theo mô hình Follow-the-Sun giúp kéo dài giờ làm việc hiệu quả trên nhiều múi giờ, rút ngắn chu kỳ bàn giao mà không yêu cầu bất kỳ ai làm việc ngoài giờ hành chính thông thường. Đối với các doanh nghiệp cần đẩy nhanh tiến độ ra mắt sản phẩm mà không mở rộng đội ngũ, đây là một trong những mô hình ít được tận dụng nhất trong phát triển phần mềm phân tán.

Thách thức ở đây là hầu hết các đội nhóm tuyên bố áp dụng mô hình này trên thực tế lại không làm vậy. Đây là những gì mô hình này thực sự đòi hỏi, và cách Gradion triển khai mô hình đó giữa Hamburg và Ho Chi Minh City.

Phát triển phần mềm theo mô hình Follow-the-Sun là gì?

Follow-the-Sun (FTS) là, theo lời của Carmel, Espinosa và Dubinsky — những nhà nghiên cứu đã đặt nền móng học thuật cho mô hình này — một loại quy trình làm việc tri thức toàn cầu được thiết kế nhằm rút ngắn thời gian đưa sản phẩm ra thị trường. Công việc được bàn giao giữa các đội nhóm phân tán về mặt địa lý khi mỗi địa điểm kết thúc ngày làm việc của mình. Đội tiếp nhận bắt đầu ngay lập tức. Quá trình phát triển tiếp tục không gián đoạn.

Với hai địa điểm, mô hình này kéo dài giờ làm việc hiệu quả lên 16 tiếng mỗi ngày. Với ba địa điểm, con số này là 24 tiếng. IBM là đơn vị tiên phong áp dụng phương pháp này vào giữa thập niên 1990. Lần thử đầu tiên của họ thất bại, không phải vì ý tưởng sai, mà vì quy trình bàn giao hàng ngày không được thực hiện nhất quán.

Đó là điều mà hầu hết các mô tả đều bỏ qua. Follow-the-Sun không phải là một sắp xếp về múi giờ. Đó là một kỷ luật vận hành. Múi giờ là điều kiện tiên quyết. Kỷ luật mới là thứ tạo ra kết quả.

Tại sao là Hamburg và Ho Chi Minh City?

Hamburg hoạt động theo CET (UTC+1) vào mùa đông và CEST (UTC+2) vào mùa hè. Ho Chi Minh City hoạt động theo ICT (UTC+7) quanh năm. Chênh lệch múi giờ là 5 tiếng vào mùa hè và 6 tiếng vào mùa đông.

Gradion cũng vận hành một trung tâm kỹ thuật tại Cairo. Ai Cập sử dụng EET (UTC+2) quanh năm vì nước này đã bãi bỏ giờ mùa hè vào năm 2011. Điều này đặt Cairo vào cùng dải múi giờ với Hamburg: trùng nhau vào mùa hè, chênh lệch một tiếng vào mùa đông.

Theo thuật ngữ FTS, Hamburg và Cairo cùng tạo thành một neo phía tây duy nhất, chứ không phải hai điểm chuyển tiếp độc lập. Hai địa điểm này chia sẻ khung giờ sáng của châu Âu và khu vực MENA, tăng cường năng lực kỹ thuật tổng hợp ở phía tây, đồng thời mở rộng phạm vi thị trường của Gradion vào khu vực MENA. Công việc được chuyển giao về phía đông sang HCMC khi châu Âu và MENA đóng cửa, rồi trở lại đội ngũ phía tây vào sáng hôm sau.

Điều này tạo ra một khung thời gian chồng lấp tự nhiên. Hamburg và Cairo bắt đầu lúc 09:00 giờ địa phương. HCMC lúc đó đang ở 14:00 ICT — buổi chiều, đang trong giai đoạn sản xuất cao điểm. Một phiên đồng bộ có cấu trúc từ 09:00 đến 11:00 CET giúp cả hai phía có ngữ cảnh chung. Các đội phía tây sau đó bàn giao. HCMC tiếp tục công việc đến tối.

Đến khi HCMC đóng cửa lúc 18:00 ICT, Hamburg đang ở 12:00-13:00 CET ngày hôm sau. Công việc đã hoàn thành đang chờ sẵn. Quá trình xem xét bắt đầu. Chu kỳ tiếp tục.

Mười sáu giờ làm việc kỹ thuật hiệu quả. Không ai làm ngoài giờ hành chính. Không cần đến những nỗ lực phi thường.

Đây cũng là nơi dấu ấn của Gradion phản ánh điều gì đó sâu sắc hơn phép tính múi giờ đơn thuần. Hamburg mang đến sự nghiêm túc trong kỹ thuật theo phong cách Đức, các quyết định kiến trúc có cấu trúc, tài liệu hóa kỷ luật, tiêu chuẩn bàn giao chính xác. Cairo bổ sung sự gần gũi với thị trường MENA và chiều sâu kỹ thuật cho neo phía tây. HCMC mang lại tốc độ bàn giao, sản lượng lớn, vòng lặp cải tiến nhanh, một đội ngũ kỹ sư cấp cao được xây dựng để di chuyển. Cùng nhau, họ không chỉ phủ thêm giờ làm việc. Họ phủ thêm cả lĩnh vực.

Điều gì giúp mô hình này hoạt động hiệu quả trong thực tế?

Kroll et al. (2013) đã xem xét 36 thực tiễn tốt nhất trong các triển khai Follow-the-Sun. Phát hiện của họ: chất lượng bàn giao là yếu tố quan trọng nhất duy nhất. Việc chuyển giao ngữ cảnh kém chất lượng là nguyên nhân khiến FTS thất bại, không phải khoảng cách múi giờ hay sự khác biệt văn hóa.

Trên thực tế, một quy trình FTS vận hành hiệu quả đòi hỏi bốn yếu tố:

Tài liệu bàn giao có cấu trúc. Mỗi nhiệm vụ được chuyển giao giữa các địa điểm phải mang theo trạng thái hiện tại, các vấn đề tồn đọng, các quyết định đã được đưa ra, và hành động tiếp theo cần thực hiện. Một buổi bàn giao bằng lời nói qua các múi giờ không phải là bàn giao thực sự. Đó chỉ là một giả định sẽ gây tốn hàng giờ đồng hồ.
Khung giờ chồng lấp cố định. Khung thời gian chồng lấp không phải để bắt kịp tiến độ. Đó là để đồng bộ hóa. Giải quyết các vấn đề tồn đọng. Xác nhận ưu tiên. Loại bỏ sự mơ hồ trước khi đội tiếp nhận làm việc mà không có sự hỗ trợ. Tại Gradion, khung thời gian này là cố định, không linh hoạt.
Giao tiếp ưu tiên bất đồng bộ. Ngoài khung giờ chồng lấp, cả hai đội vận hành theo phương thức bất đồng bộ. Các quyết định không thể chờ đợi một cuộc trò chuyện trực tiếp. Tài liệu hóa, xem xét PR bất đồng bộ, và các quyết định kiến trúc bằng văn bản không phải là gánh nặng hành chính. Chúng là hệ điều hành của mô hình.
Hạ tầng bàn giao liên tục. Các pipeline tự động hóa, môi trường dùng chung, và độ bao phủ kiểm thử là những yêu cầu không thể thiếu. Một quy trình build mà chỉ đội Hamburg biết cách chạy là sự chậm trễ sáu tiếng mỗi khi HCMC cần đến nó.

Follow-the-Sun không phải là:

FTS thường xuyên được tuyên bố nhưng hiếm khi được thực hành thực sự. Treinen và Miller-Frost (2006), trong một nghiên cứu tình huống trên IBM Systems Journal, đã ghi chép lại cả những triển khai FTS thành công lẫn thất bại. Thất bại phổ biến nhất: các đội làm việc song song thay vì tuần tự. Cả hai địa điểm đều đang hoạt động. Nhưng không bên nào xây dựng dựa trên kết quả của bên kia. Hệ quả là sự trùng lặp, xung đột merge, và gánh nặng phối hợp đã xóa bỏ hoàn toàn lợi thế múi giờ.

Một nhà cung cấp mô tả mô hình của họ là Follow-the-Sun nhưng không thể mô tả quy trình bàn giao của họ là gì thì không thực sự đang vận hành FTS. Họ chỉ đang điều hành một đội ngũ phân tán với định vị thương hiệu được đánh bóng hơn.

Sự phân biệt này dẫn đến các kết quả khác nhau. Phát triển phân tán song song mở rộng năng lực. Phát triển Follow-the-Sun mở rộng tốc độ. Một mô hình thêm kỹ sư. Mô hình kia rút ngắn lịch trình.

Mô hình Gradion trong thực tế

Cấu trúc của Gradion được thiết kế dựa trên các nguyên tắc FTS ngay từ đầu, không phải được điều chỉnh lại từ một cấu trúc có sẵn.

Đội Hamburg giữ vai trò neo đối với quan hệ khách hàng, các quyết định kiến trúc và quyền sở hữu sprint. Cairo củng cố neo phía tây, mở rộng chiều sâu kỹ thuật và phạm vi thị trường MENA trong cùng dải múi giờ. HCMC đảm nhận khối lượng kỹ thuật chính với tư cách là đối tác bàn giao toàn diện, không phải là nguồn nhân lực dự phòng.

Các buổi bàn giao được ghi chép bằng văn bản. Các khung giờ chồng lấp được bảo vệ. Giao tiếp bất đồng bộ là mặc định, không phải phương án dự phòng.

Đối với khách hàng, điều này có nghĩa là một vấn đề tồn đọng được giải quyết lúc 17:00 CET không phải chờ đến 09:00 sáng hôm sau. Vấn đề đó sẽ được HCMC xử lý ngay trong buổi tối. Kết quả đã sẵn sàng khi Hamburg và Cairo mở cửa.

Tính theo từng sprint, từng quý, sự rút ngắn đó là có thể đo lường được. Đó cũng là lý do mô hình này đòi hỏi quản trị, không chỉ địa lý, để giảm thiểu rủi ro bàn giao ở quy mô lớn.

Những câu hỏi cần đặt ra cho nhà cung cấp Follow-the-Sun

Nếu bạn đang đánh giá xem một nhà cung cấp có thực sự vận hành theo mô hình FTS hay không, hãy đặt ra ba câu hỏi:

1. Quý vị ghi chép và chuyển giao công việc giữa các địa điểm vào cuối ngày như thế nào? Tài liệu bàn giao trông như thế nào?
2. Khung giờ chồng lấp cố định của quý vị là gì và những ai bắt buộc phải có mặt?
3. Quý vị xử lý một vấn đề tồn đọng xuất hiện sau khi bàn giao như thế nào?

Nhà cung cấp nào trả lời cả ba câu hỏi với những chi tiết cụ thể là đang thực sự vận hành mô hình này. Nhà cung cấp nào chỉ mô tả sự phân bổ múi giờ mà không mô tả quy trình bàn giao của họ thì không phải vậy.

Phát triển phần mềm Follow-the-Sun là một quyết định về mô hình vận hành. Địa lý tạo ra khả năng. Kỷ luật tạo ra kết quả.

Nguồn tham khảo

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