Pragmatic Programmer – Topic 50: Coconuts Don't Cut It — Đừng copy

Hồi còn làm ở một công ty cũ, mình chứng kiến cảnh này: team họp daily stand-up mỗi tuần một lần, sprint ghi là 4 tuần nhưng thực tế kéo dài 6-8 tuần. Khi bị hỏi, câu trả lời luôn là "bên mình đang chạy Scrum mà" — kèm theo một cái Jira board mở sẵn trên màn hình. Mọi thứ trông rất đúng, chỉ có điều phần mềm vẫn ra chậm như cũ.

Mở đầu

Topic 50 của sách kể chuyện này, mà mình nhớ hoài: có một hòn đảo ở Melanesia, dân bản địa chưa từng thấy máy bay. Người lạ tới, xây đường băng, dựng tháp kiểm soát, mỗi ngày "loài chim cơ khí" bay vào mang theo cả núi của cải. Sau chiến tranh, họ rời đi.

Dân đảo khôi phục vận may bằng cách dựng lại y nguyên một sân bay — tháp, thiết bị, tất cả — bằng dây leo, vỏ dừa, tàu lá cọ. Máy bay không tới. Họ bắt chước đúng hình thức nhưng thiếu nội dung. Giới nhân học gọi đó là "cargo cult", và hai tác giả chốt: "All too often, we are the islanders."

Bẫy vỏ dừa trong ngành phần mềm

Điều dễ chịu nhất của cargo cult là nó cho cảm giác mình đang làm đúng. Có stand-up, có retro, có board, có tài liệu — nhìn từ ngoài, không ai phân biệt được team mình với team chạy thật.

Nhưng mấy thứ dễ thấy đó — nhãn dán, nghi thức họp, "câu thần chú" như stand up hay iteration — không phải thứ tạo ra ma thuật. Sách kể về team tin rằng cứ gọi tên đúng là mọi chuyện sẽ ổn, y như đọc chú. Kết quả thì ai cũng đoán được.

Cái bẫy này nguy hiểm vì nó lan qua đồng nghiệp chứ không qua tài liệu. Người mới vào thấy nhóm cũ họp sao thì họp vậy. Ba năm sau, không ai còn nhớ vì sao mình đang chạy phương pháp này nữa.

Ảnh: RDNE Stock project — Pexels

Bối cảnh là thứ không copy được

Đoạn Context Matters đáng suy nghĩ nhất. Hiện nay có xu hướng bắt chước quy trình của Spotify, Netflix, Stripe, GitLab. Mỗi công ty đó có cách làm riêng, và cách làm đó đúng với họ.

Tác giả đặt loạt câu hỏi nên in ra dán tường: Bạn có cùng thị trường, cùng ràng buộc, cùng cơ hội không? Cùng trình độ chuyên môn, cùng quy mô tổ chức? Cùng kiểu quản lý, cùng văn hóa, cùng tập người dùng và yêu cầu không?

Nếu câu trả lời là "không" (và thường là không), thì copy quy trình của người ta chỉ là dựng sân bay bằng vỏ dừa. Chính Spotify hay Netflix cũng không chạy đúng cái quy trình mà thiên hạ ca tụng khi họ còn đang lớn — họ liên tục đổi. Đó mới là bí quyết thật.

Cách làm đúng: thử, giữ phần tốt, bỏ phần thừa

Tip 87 gói gọn trong một câu: Do What Works, Not What's Fashionable. Làm sao biết cái gì hiệu quả? Bằng kỹ thuật nền tảng nhất của cả cuốn sách: Thử đi. Thí điểm với một team nhỏ, giữ phần chạy tốt, bỏ phần còn lại như chi phí vô ích. Không ai hạ bậc tổ chức của mình chỉ vì nó vận hành khác Spotify.

Sách nhắc lại ý ở topic 48: mục đích của một phương pháp là giúp người ta làm việc cùng nhau, chứ không phải để thành quy trình chuẩn mực. "One size fits no one well". Về chứng chỉ, tác giả nói thẳng nhiều chương trình xây trên giả định học viên phải ghi nhớ và tuân theo luật — trong khi thứ mình cần là khả năng nhìn xa hơn luật đang có. Ngay cả Scrum cũng không đủ hướng dẫn ở tầng kỹ thuật cho team, cũng không đủ ở tầng quản trị cho lãnh đạo.

Mục tiêu thật sự là gì

Mục tiêu không phải "làm Scrum", "làm agile". Mục tiêu là giao phần mềm chạy được, cho người dùng năng lực mới, ngay khi họ cần — không phải tuần sau, tháng sau, mà là bây giờ.

Nếu đang giao theo năm, cắt xuống tháng. Từ tháng xuống tuần. Từ sprint 4 tuần, thử 2 tuần, rồi 1 tuần, rồi hằng ngày, cuối cùng là theo yêu cầu. Giao theo yêu cầu không có nghĩa là phải deploy mỗi phút — giao khi người dùng cần, khi có ý nghĩa kinh doanh (Tip 88).

Để tới đó cần hạ tầng thật vững — nội dung topic 51, Pragmatic Starter Kit: làm trên nhánh trunk chính thay vì branch dài, dùng feature switch để mở tính năng cho nhóm người dùng chọn lọc.

Ảnh: fauxels — Pexels

Chỗ khó khi áp dụng

Phần khó nhất không nằm ở kỹ thuật mà ở áp lực phải trông giống người ta. Khi sếp đọc một bài về Spotify model, kỳ vọng đổ xuống. Lúc đó nói "để tụi mình thí điểm 6 tuần rồi tính" nghe rất yếu so với "dạ triển khai luôn". Thêm nữa, bỏ khó hơn giữ: một nghi thức đã bám vào lịch họp, vào KPI, vào thói quen của 20 người — muốn bỏ phải có bằng chứng, mà bằng chứng cần thời gian và người theo dõi. Bản thân việc thử cũng có giá: thí điểm xong mà không ai tổng kết, không lan ra team khác, thì thành ra vừa trả giá cho một sân bay giả thứ hai.

Bài học rút ra

• Hình thức không tạo ra kết quả. Có board, có stand-up, có retro không có nghĩa là đang chạy tốt. Câu hỏi phải là: cái này có giúp team ra phần mềm nhanh hơn không?
• Copy quy trình công ty khác là bỏ qua bối cảnh. Spotify, Netflix không có cùng quy mô, thị trường, văn hóa. Kể cả họ cũng không chạy đúng quy trình đang được ca tụng khi họ còn nhỏ.
• Cách kiểm chứng duy nhất là thử. Thí điểm nhỏ, giữ phần chạy tốt, bỏ phần thừa. Đây là kỹ thuật nền tảng của cả cuốn sách, không phải mẹo phụ.
• Đo bằng vòng giao hàng, không đo bằng nghi thức. Rút ngắn chu kỳ: năm → tháng → tuần → ngày → theo yêu cầu. Đó là thước đo thật.
• Lấy mảnh tốt từ nhiều phương pháp. Scrum thiếu hướng dẫn ở tầng kỹ thuật và tầng quản trị, nên bám một phương pháp duy nhất là thiếu.

Kết

Mình nghĩ điều đáng nhớ nhất của topic này không phải "đừng dùng Scrum", mà là câu hỏi vì sao. Vì sao team đang dùng phương pháp này? Nó có hợp với công việc trước mắt không, hay chỉ hợp với bài blog mình đọc tuần trước?

Vậy team của bạn — lần cuối cùng ai đó hỏi "vì sao mình đang làm thế này" là khi nào?