Những phụ thuộc của Squad
Với nhiều Squad sẽ luôn có sự phụ thuộc nhất định. Sự phụ thuộc không nhất thiết là xấu – Squad đôi lúc cần phải làm việc cùng nhau thì mới tạo ra được điều tuyệt vời. Tuy nhiên mục tiêu của chúng tôi là xây dựng Squad càng tự chủ càng tốt, đặc biệt là giảm thiểu sự phụ thuộc làm cản trở và chậm Squad.
Để cải thiện việc này, chúng tôi thường xuyên hỏi các Squad xem họ phụ thuộc vào Squad nào, và mức độ mà sự phụ thuộc này làm cản trở và chậm công việc của họ. Đây là một ví dụ:
>> Triển khai Agile quy mô lớn tại Spotify phần 1
Tiếp theo, chúng tôi sẽ bàn luận về cách để loại bỏ những sự phụ thuộc có hại, đặc biệt là các phụ thuộc liên-Tribe. Việc này dẫn đến ưu tiên hóa lại, tổ chức lại, thay đổi kiến trúc hoặc các giải pháp kỹ thuật.
Các khảo sát cũng giúp chúng tôi nhận ra những khuôn mẫu về sự phụ thuộc lẫn nhau giữa các Squad – ví dụ như là càng ngày càng có nhiều Squad bị chậm lại do các vận hành. Chúng tôi sử dụng một biểu đồ đơn giản để theo dõi sự tăng giảm qua thời gian của một số “loại” phụ thuộc.
Scrum cũng có một phương pháp gọi là “Scrum of Scrums”, một cuộc họp đồng bộ hóa mà ở đó mỗi nhóm có một người đại diện sẽ gặp nhau để bàn luận về sự phụ thuộc. Chúng tôi ít sử dụng “Scrum of Scrums” tại Spotify, lý do chính là bởi mỗi Squad đều tương đối độc lập và chúng tôi không cần đến cuộc họp điều phối.
Thay vào đó, Scrum of Scrums sẽ được diễn ra “tùy theo yêu cầu”. Mới đây chúng tôi có một dự án cần đến sự hợp tác của một số Squad trong khoảng thời gian vài tháng.
Để có thể làm được việc này, các nhóm có những cuộc họp đồng bộ hằng ngày. Tại đây họ xác định và giải quyết sự phụ thuộc giữa các Squad. Họ dùng một bảng dán các sticky note để theo dõi những sự phụ thuộc chưa được giải quyết.
Khởi nguồn phổ biến của những vấn đề phụ thuộc ở nhiều công ty là sự đối đầu giữa sự phát triển và vận hành. Phần lớn các công ty chúng tôi từng làm việc đều gặp phải vấn đề về sự chuyển giao từ giai đoạn phát triển sang vận hành, đi kèm với những xích mích và trì hoãn.
Tại Spotify chúng tôi có các đội vận hành riêng biệt, nhưng việc của họ không phải để phát hành sản phẩm hộ các Squad – mà việc của họ là cung cấp sự hỗ trợ cần thiết để Squad có thể tự mình phát hành mã của mình; sự hỗ trợ có thể là về hạ tầng cơ sở, các kịch bản và các vấn đề thường ngày. Nhìn chung, họ “xây dựng con đường cho sản xuất.”
Đây là một sự hợp tác mang tính phi chính quy nhưng vô cùng hiệu quả, dựa trên sự giao tiếp mặt đối mặt thay vì những tài liệu chi tiết về quy trình.
Các Chapter và Guild
Đâu cũng có sự hiện diện của sự bất lợi. Sự bất lợi tiềm tàng khi muốn đạt đến sự tự quản tuyệt đối là sự suy giảm về kinh tế quy mô. Kiểm thử ở Squad A có thể đang phải vật lộn với vấn đề mà kiểm thử ở Squad B đã giải quyết tuần trước. Nếu tất cả các kiểm thử viên của các Squad và các Tribe có thể tập hợp lại thì họ sẽ có thể chia sẻ kiến thức và tạo ra những công cụ giúp ích cho tất cả các Squad.
Khóa học ScrumMaster lấy chứng chỉ quốc tế ScrumAlliance
Nếu mỗi Squad có tính hoàn toàn tự chủ mà lại thiếu đi sự giao tiếp giữa các Squad, thì ý nghĩa của công ty là gì? Spotify có thể được phân chia thành 30 công ty khác nhau.
Vì vậy chúng tôi có các Chapter và Guild. Đây như là keo dính gắn kết toàn công ty, nó mang đến kinh tế quy mô mà không phải hi sinh quá nhiều sự tự chủ.
Chapter là một gia đình bé nhỏ gồm những người có kỹ năng giống nhau và năng lực tương đồng, trong một Tribe.
Mỗi Chapter sẽ gặp mặt thường xuyên để bàn về những lĩnh vực chuyên môn và những thử thách cụ thể mà họ đang phải đối mặt – ví dụ Chapter Kiểm thử, Chapter Phát triển ứng dụng web, Chapter Backend.
Lãnh đạo Chapter (Chapter lead) là nhà quản lý nghiệp vụ (line manager) của các thành viên Chapter của mình, với toàn bộ những trách nhiệm truyền thống như phát triển nhân sự, thiết lập bảng lương, v.v… Tuy nhiên, Chapter Lead vẫn là thành viên của Squad và tham gia vào công việc hằng ngày. Điều này giúp cho những nhà lãnh đạo luôn bám sát với thực tế.
Thế nhưng, thực tế luôn hỗn loạn hơn những hình ảnh đẹp đẽ – bức hình trên là một ví dụ. Thành viên Chapter không được phân chia đồng đều giữa các Squad, một số Squad có rất nhiều những nhà phát triển web, một số lại không có. Tuy nhiên hình trên sẽ vẫn cho bạn một cái nhìn cơ bản.
Guild lại là “cộng đồng quan tâm\yêu thích” có quy mô rộng và hữu cơ hơn. Đây là một nhóm của những người muốn chia sẻ kiến thức, công cụ, mã nguồn và những phương pháp thực hành. Chapter luôn nằm trong nội bộ của Tribe, trong khi Guild thường trải rộng ra toàn tổ chức. Ví dụ như: Guild Công nghệ web, Guild Kiểm thử, Guild Huấn luyện viên Agile, v.v…
Một Guild thường bao gồm tất cả các Chapter làm việc trong một lĩnh vực và những thành viên của nó, ví dụ Guild Kiểm thử bao gồm tất cả các kiểm thử viên của các Chapter và tất cả những người có mối quan tâm đến lĩnh vực kiểm thử đều có thể gia nhập Guild này.
Mỗi Guild có “Điều phối viên Guild”, người này chỉ thực hiện công việc điều phối :o)
Một ví dụ về cách Guild đang hoạt động mà chúng tôi có gần đây là “Web Guild Unconference”, một sự kiện mở, nơi tất cả các nhà phát triển web tại Spotify tụ họp tại Stockholm để bàn luận về những thử thách và cách giải quyết những vấn đề trong lĩnh vực của họ.
Một ví dụ khác là Guild Huấn luyện viên Agile. Tất cả các huấn luyện viên ở khắp tổ chức, liên tục chia sẻ kiến thức và gặp mặt thường xuyên để cùng hợp tác và cải tiến những vấn đề cấp cao của tổ chức, mà chúng tôi sẽ giám sát trên bảng cải tiến.
Đợi chút, đây không phải là một cách tổ chức dạng ma trận sao?
Đúng, chính là kiểu như vậy đấy. Tuy nhiên, đây là một kiểu ma trận khác với những gì chúng ta thường biết đến. Trong nhiều tổ chức ma trận, những người có cùng kỹ năng sẽ bị đẩy về những bộ phận chức năng, tại đây họ sẽ được giao những dự án và báo cáo với người quản lý của bộ phận chức năng đó.
Ở Spotify rất ít khi làm việc này. Ma trận của chúng tôi có trọng số hướng theo phân phối.
Có nghĩa là, mọi người sẽ được nhóm vào những Squad ổn định ở cùng khu vực địa lý, nơi những người có kỹ năng khác nhau sẽ hợp tác và tự tổ chức để đưa đến những sản phẩm tuyệt vời nhất. Đấy là trục dọc của ma trận, và là trục căn bản vì đây là cách họ được nhóm lại và nơi họ dành phần lớn thời gian của mình để làm việc.
Trục ngang là chia sẻ kiến thức, công cụ và mã nguồn. Công việc của Chapter Lead là điều phối và hỗ trợ việc này.
Trong thuật ngữ nhóm ma trận, hãy nghĩ về trục dọc như là “cái gì” và trục ngang là “như thế nào”. Cấu trúc ma trận đảm bảo rằng mỗi thành viên Squad sẽ nhận được sự hướng dẫn về “những gì sẽ được xây dựng tiếp” cũng như là cách để “xây dựng nó tốt”.
Việc này hoàn toàn khớp với mô hình “chuyên gia và doanh nhân” (professor and entrepreneur) được giới thiệu bởi Mary và Tom Poppendieck. PO đóng vai trò là “doanh nhân” hoặc “product champion”, tập trung vào việc mang đến một sản phẩm tuyệt vời, trong khi Chapter Lead là “chuyên gia” hoặc “competency leader”, tập trung vào kỹ thuật xuất sắc.
Có một sự căng thẳng “lành mạnh” giữa các vai trò này, doanh nhân sẽ có xu hướng muốn đẩy nhanh tốc độ và đốt cháy giai đoạn, trong khi các chuyên gia lại muốn chậm lại và xây dựng mọi thứ sao cho hoàn chỉnh nhất. Cả hai khía cạnh này đều cần thiết, vì vậy đây được cho là một sự căng thẳng “lành mạnh”.
Còn về kiến trúc thì sao?
Công nghệ Spotify là hướng dịch vụ cao độ. Chúng tôi có hơn 100 hệ thống khác nhau, và mỗi hệ thống được duy trì và triển khai riêng biệt. Bao gồm dịch vụ backend, ví dụ quản lý danh mục bài hát, tìm kiếm, thanh toán hay ứng dụng khách, tiêu biểu là ứng dụng chơi nhạc trên iPad, và những thành phần cụ thể như radio, hay mục “what’s new” trên ứng dụng chơi nhạc.
Về mặt kỹ thuật, bất cứ ai đều có thể chỉnh sửa hệ thống. Bởi lẽ Squad là những nhóm tính năng hiệu quả, họ thường phải cập nhật hệ thống để có thể đưa một tính năng mới vào sản xuất.
Rủi ro của mô hình này là kiến trúc của hệ thống có thể bị rối loạn nếu không để ý đến sự thống nhất của toàn bộ hệ thống.
Để giảm thiểu rủi ro này, chúng tôi có một “System Owner”. Mọi hệ thống có một hoặc hai System Owner (chúng tôi khuyến nghị hai người). Đối với các hệ thống đề cao sự vận hành, System Owner là một cặp Dev-Ops – một người có quan điểm của nhà phát triển và một người chú trọng vào vận hành.
System Owner là người được tìm đến khi có bất kì một vấn đề gì về kỹ thuật hay kiến trúc liên quan đến hệ thống. Anh ta là điều phối viên và hướng dẫn những người viết mã của hệ thống để đảm bảo họ không “dẫm đạp” lên nhau. Anh ta tập trung vào những vấn đề như là chất lượng, tài liệu hóa, nợ kỹ thuật, tính ổn định, khả năng mở rộng và quy trình phát hành.
System Owner không phải là một nút cổ chai hay là kiến trúc sư trong tháp ngà. Anh ta không trực tiếp đưa ra quyết định, viết mã, hay phát hành. Anh ta thường là thành viên của Squad hoặc Chapter Lead có những trách nhiệm thường ngày khác ngoài vai trof System Owner. Tuy nhiên, thỉnh thoảng anh ta sẽ dành một “ngày chỉ để làm System Owner” và dọn dẹp hệ thống. Thường chúng tôi cố gắng giữ khoảng thời gian này không vượt quá 10% thời gian của một người, tuy nhiên nó còn thay đổi tùy vào các hệ thống khác nhau.
Chúng tôi cũng có một kiến trúc sư trưởng, người điều phối công việc về các vấn đề kiến trúc cấp cao, bao trùm nhiều hệ thống. Anh ấy đánh giá sự phát triển của hệ thống mới để đảm bảo chúng phù hợp với tầm nhìn kiến trúc của chúng tôi và tránh những sai lầm phổ biến. Phản hồi chỉ là gợi ý đầu vào – quyết định cuối cùng về thiết kế hệ thống vẫn phụ thuộc Squad.
Mọi thứ vận hành như thế nào?
Spotify đã phát triển rất nhanh – trong vòng hơn 3 năm chúng tôi đã mở rộng từ 30 nhân viên lên đến 250 người trong lĩnh vực công nghệ – cho nên chúng tôi đã từng nếm trải nỗi đau của việc mở rộng. Mô hình mở rộng này – với Squad, Tribe, Chapter và Guild – mới được giới thiệu suốt một năm vừa qua,cho nên mọi người mới chỉ đang làm quen với nó. Nhưng cho đến nay, dựa vào các khảo sát và sự phản tư, mô hình mở rộng có vẻ vận hành khá tốt. Và nó cho chúng ta một điều gì đó để “trở thành”. Mặc dù tăng trưởng nhanh nhưng mức độ hài lòng của nhân viên cũng liên tục tăng lên: Tháng 4 năm 2012 mức độ hài lòng đạt 4,4 trên 5.
Tuy nhiên, cũng như với tất cả các tổ chức đang phát triển, những giải pháp ngày hôm nay sinh ra những khó khăn trong ngày mai. Vì vậy hãy tiếp tục theo dõi nhé, mọi thứ vẫn chưa kết thúc.
Tác giả: Henrik Kniberg & Anders Ivarsson | Nguồn:blog.crisp.se
