Ứng Dụng SCRUM Cho Team Phân Tán (Phần 1)

Bài viết này yêu cầu các bạn phải có kiến thức cơ bản về Agile và Scrum.

Như các bạn đã biết, phương thức quản lý project theo triết lý Agile, cụ thể là Scrum tập trung vào con người, khuyến khích các thành viên tích cực trao đổi và hợp tác với nhau trong quá trình estimation và thực hiện nhiệm vụ. Thông qua đó, không chỉ phát triển một sản phẩm với chất lượng cao mà còn phát triển năng lực làm việc, tinh thần teamwork và kĩ năng giao tiếp, trình bày, giải quyết vấn đề của mỗi thành viên trong team. Tóm lại, nó được phát triển dành cho một team mà các thành viên ngồi cạnh nhau hoặc tương đối gần nhau trong quá trình làm việc.

Thế nhưng thật không may, trong thời kì toàn cầu hoá và sự phát triển mạnh mẽ của công nghệ ngày nay, điều kiện lý tưởng là tất cả các thành viên trong Project ngồi cạnh nhau rất hiếm khi đạt được. Trong khi đó nhiệm vụ yêu cầu họ đạt được mục tiêu là tạo ra một sản phẩm chất lượng cao đồng thời phát triển năng lực của các thành viên vẫn còn nguyên vẹn.

Thực tế cho thấy có quá nhiều khó khăn khi cố gắng áp dụng Scrum cho một team phân tán. Từ việc họp estimate đầu sprint cho tới những khó khăn hằng ngày như việc làm sao Scrum Master có thể tổ chức tốt được Daily Stand-Up Meeting khi mà sự cách biệt về địa lý là rất lớn, có khi dẫn tới sự khác biệt về múi giờ; rồi thì làm sao để Product Owner có thể thường xuyên kiểm tra đánh giá các bản demo sản phẩm khi không có sự có mặt và giải thích trực tiếp của các thành viên trong team...

Có nhiều ý kiến cho rằng việc vận hành Scrum trong điều kiện cách biệt về địa lý lớn như vậy dường như là một việc "bất khả thi". Tuy nhiên theo ý kiến cá nhân của mình thì đó là điều "khả thi", thực tế đã chứng minh có nhiều trường hợp cố gắng thử các giải pháp, các phương án điều chỉnh sao cho phù hợp và kết quả là thành công. (yeah3).

Trong phần 1 của bài viết, mình sẽ lần lượt giới thiệu tới các bạn.

• II. Lý do tạo nên một team phân tán
• III. Các mô hình biến đổi SRUM cho team phân tán

Phần 2 mình sẽ đưa ra IV. Những thử thách và Kĩ thuật áp dụng để giải quyết vấn đề

Nào hãy bắt đầu tìm hiểu lý do tạo nên một team phân tán hay khiến cho một team trở thành team phân tán!

Nếu là người trong ngành IT chắc hẳn các bạn cũng nhận thấy, trong thời gian gần đây số lượng team phân tán có xu hướng tăng lên rất nhanh, đặc biệt là trong thị trường Việt Nam.

Có 4 nguyên nhân chính dẫn đến hệ quả ấy

1. Xu hướng Outsourcing

Các công ty IT làm sản phẩm luôn muốn giảm cost phát triển, tăng chất lượng và giảm thời gian phát triển của sản phẩm để tăng sức cạnh tranh của mình trên thị trường. Giải pháp cho tất cả những yêu cầu đó tất nhiên là một "Biệt đội đánh thuê" chuyên nghiệp. Có thể thấy rằng gần đây các công ty Nhật Bản đang dần trở thành đối tác lớn nhất của các công ty Outsourcing trong nước.

Và hệ quả của nó là PO (Product Owner) thường là người của khách hàng và ngồi tách biệt với Development Team và Scrum Master.

2. Tuyển dụng nhân tài

Trong cơn khát nguồn nhân lực chất lượng cao để tạo ra sự đột phá trong sản phẩm, nhiều ông lớn sẵn sàng ra khơi, bỏ ra nhiều tiền mở các công ty Offshore chỉ để tìm kiếm Nhân tài, họ chấp nhận bỏ qua một bên những khó khăn gây ra bởi cách biệt địa lý, sự khác biệt trong chính sách của của các chính phủ...

3. Các thương vụ M&A

Nếu để ý thì các bạn có thể thấy những phi vụ M&A lên báo hằng ngày, những phi vụ đình đám như Softbank mua lại ARM, Microsoft mua lại Skype, Facebook thâu tóm Snapchat...vv thì có thể nói là hàng tháng. Tốc độ phát triển như vũ bão của công nghệ và làn sóng thay đổi phương thức sản xuất nó gây lên trên toàn cầu thúc đẩy các công ty phải đấu tranh mở rộng và thay đổi liên tục để tồn tại và chiếm lính thị trường. Và tất nhiên họ sẽ muốn giữ lại chi nhánh và các nhân viên của công ty họ đã thâu tóm được.

4. Văn hoá doanh nghiệp mới

Ngày càng có nhiều công ty cho phép nhân viên của mình được làm ở nhà, miễn sao họ đảm bảo commit được 8 tiếng làm việc mỗi ngày. Mục đích của họ là cắt giảm thời gian, chi phí đi lại cho nhân viên, giảm chi phí thuê văn phòng và hoạt động của công ty. Đương nhiên quy định thoải mái thế này phải dựa trên nền tảng là ý thức của người lao động phải rất tốt. Vì vậy nó hay được áp dụng ở các nước phương tây, đó là lý do vì sao mình đặt mục này ở cuối cùng =))

Với những nguyên nhân và yêu cầu được phân tích ở trên, chúng ta sẽ cùng nhau đi tới mục thứ 3 - Các mô hình biến đổi SRUM được đề xuất cho team phân tán.

1. Mô hình Scrum tập trung

Đây là mô hình chỉ có một Scrum duy nhất được vận hành trong team. Các members ở các chi nhánh khác nhau phải cùng tiến hành Daily Stand-up Meeting, planning, và họp Cải tiến sprint hay demo sản phẩm cùng nhau.

Mô hình này thích hợp cho các team mà sự chia cách không quá sâu sắc; nghĩa là số lượng thành viên ở các chi nhánh nhỏ không nhiều, sự khác biệt về timezone không lớn (cùng lắm chỉnh lệch 2 múi giờ).

Trong thực tế thì mô hình này khá ít, vì nó không thích hợp áp dụng cho các team mà có sự khác biệt lớn về timezone.

2. Mô hình nhiều Scrum độc lập

Ở mô hình này mỗi chi nhánh chạy một mô hình Scrum riêng cho mình.

Mô hình này chạy ổn khi sự chia tách khiến team tách thành các phần tương đối đồng đều và hoạt động của các team con không có nhiều liên hệ hay phụ thuộc vào nhau. Bởi vậy mô hình này còn hiếm gặp hơn mô hình Scrum tập trung.

3. Scrum lồng trong Scrum

Với mô hình này, mỗi chi nhánh sẽ chạy một Scrum của riêng mình, tuy nhiên các Scrum này có mối liên hệ mật thiết với nhau chứ không độc lập như Mô hình nhiều Scrum độc lập. Các Scrum sẽ bắt đầu và kết thúc đồng thời, Output của các Scrum chi nhánh sẽ được tổng hợp ở một Scrum tổng. Trong quá trình trao đổi và làm việc thì sẽ có sự thương lượng để phân chia task hay estimate...

Đây là mô hình khá phổ biến để vận hành Scrum cho một team phân tán.

Tuy nhiên vẫn còn có một mô hình nữa với tên gọi Mô hình Srum phân tán.

4. Mô hình Scrum phân tán

Mô hình này là sự kết hợp giữa Mô hình Scrum tập trung và Mô hình Scrum lồng trong Scrum. Nghĩa là gì, là nó sử dụng một Scrum duy nhất xuyên suốt cho cả team, với 1 Sprint Backlog chung (như Scrum tập trung). Tuy nhiên nó yêu cầu phải có Scrum Master ở mỗi chi nhánh, các Scrum Master này sẽ có nhiệm vụ update Sprint Backlog cho tất cả các member ở chi nhánh mình vào Daily Meeting.

Dưới đây là bảng tổng hợp sự khác nhau của các mô hình!

Nếu bạn đã đọc tới đây thì xin chúc mừng!

Các bạn đã vượt qua phần khó nhằn nhất - LÝ THUYẾT =)).

Ở phần 2 mính sẽ giới thiệu với các bạn những khó khăn và cách giải quyết nó, thêm vào một vài kinh nghiệm trong quá trình vận hành của bản thân và các Bro trên mạng.