Badgile là gì?

Badgile là một từ tôi dùng để mô tả một quy trình Agile "tệ". Tôi để dấu ngoặc kép quanh chữ "tệ" vì đó là một từ khá mạnh — các quy trình vốn dĩ sẽ khác nhau tùy theo từng nhóm và từng hoàn cảnh. Chúng luôn cần được đánh giá và cải tiến, và tôi không có ý cho rằng mình có “công thức thần kỳ” cho Agile. Tôi và nhóm của mình đã cùng xây dựng nên một quy trình mà tôi nghĩ là khá tuyệt, nhưng tôi không bao giờ nghĩ đến việc áp đặt nó nguyên xi lên các nhóm khác trong tổ chức khác.

Một quy trình tốt là việc áp dụng các nguyên tắc lên từng hoàn cảnh cụ thể — kết quả là có thể xuất hiện nhiều biến thể khác nhau ngay cả trong cùng một tổ chức. Khi tôi nói "tệ" hay "sai", ý tôi là nó rõ ràng tệ, là một mớ hỗn độn “bốc mùi”.

“Kể cho tôi nghe về quy trình phát triển phần mềm của bạn”

Một trong những câu hỏi tôi luôn hỏi khi phỏng vấn là ứng viên hãy mô tả quy trình phát triển phần mềm của họ. Câu hỏi này thường tiết lộ rất nhiều điều thú vị. Mặc dù ứng viên thường không có nhiều ảnh hưởng đến quy trình (điều này thật đáng tiếc, nhưng sẽ nói sau), câu hỏi này vẫn hé lộ nhiều chỉ dấu quan trọng:

• Ứng viên có mô tả rõ ràng được quy trình (hoặc sự thiếu quy trình) không, ngay cả khi quy trình ấy bản thân nó chưa rõ?
• Cảm xúc của họ về quy trình hiện tại thế nào?
• Họ có tiếng nói gì trong việc thay đổi nó không?
• Họ có thấy bức xúc không?
• Họ đã từng cố gắng cải thiện nó chưa?
• Họ có đang đóng vai “nạn nhân” không?
• Nếu có quyền thay đổi, họ sẽ làm gì?

Một phần lý do tôi hỏi cũng là vì tôi thích nghe về quy trình của các công ty khác — tôi là một "mọt quy trình" (process geek) mà. Và thú thật là có lúc tôi đào quá sâu vào các quy trình thú vị hơn mức cần thiết.

Tôi không đánh giá thấp một ứng viên chỉ vì họ đang làm việc trong một quy trình tệ — tôi hiểu và thường nói với họ rằng họ không cô đơn. Đó cũng là cơ hội để tôi cho họ thấy một tổ chức thực sự áp dụng Agile có thể trông như thế nào.

“Chúng tôi làm Agile!”

Tôi: “Hãy kể cho tôi về quy trình phát triển phần mềm của bạn.”

Ứng viên: “Chúng tôi theo Agile!”

Tôi: “Tuyệt! Hãy nói kỹ hơn, dẫn tôi qua từng bước trong quy trình.”

Ứng viên: “Chúng tôi có họp đứng hàng ngày (daily stand-ups), làm theo chu kỳ sprint.”

Tôi: “Vậy có thể nói là các bạn theo Scrum?”

Ứng viên: “Đúng, chúng tôi theo Scrum.”

Tôi: “OK, vậy Scrum này là theo sách giáo khoa (by the book) hay đã được tùy biến? Bạn hãy nói rõ thêm xem điều gì hiệu quả và điều gì không.”

Ứng viên: [Ngập ngừng] “Scrum… Stand-up… Sprints…”

Tôi: “Sprint của bạn dài bao lâu chẳng hạn?”

Ứng viên: “3 tuần.” — Thường thì là 3 tuần, nhưng cũng có lúc là 8 tuần, thậm chí có nơi là 4–6 tháng!

Và đây là lúc câu chuyện bắt đầu trật bánh. Quy trình chỉ gói gọn trong sprint và stand-up, hoặc bạn bắt đầu nghe đến những thực hành đầy nghi vấn như: việc test thì để đến sau cùng, nhóm thì 45 người (!), sprint thì do quản lý dự án (Project Manager) chọn nhiệm vụ, hoặc buổi stand-up mỗi ngày kéo dài cả tiếng đồng hồ (nhưng “rất hiệu quả”).

Có rất nhiều cờ đỏ (red flags) kiểu đó mà tôi sẽ đề cập trong những bài sau.

Tôi thường rời khỏi cuộc phỏng vấn với cảm giác hụt hẫng. Không phải vì ứng viên, mà vì thực tế đáng buồn là rất nhiều nhóm phát triển phần mềm chẳng tiến bộ là bao trong 10 năm qua. Họ đã rời khỏi mô hình Waterfall với tiến độ giả tạo và các giai đoạn rời rạc, nhưng rồi lại thay thế bằng một thứ Agile tồi tệ — không hiểu, không vận dụng đúng, thậm chí không thể gọi là quy trình.

Kết quả: nhà quản lý căng thẳng, vò đầu bứt tóc, hét vào mặt nhóm để "tăng velocity".

Đây là những câu chuyện có thật

Thật lòng mà nói, tôi không muốn làm việc trong phần lớn những môi trường như vậy. Kỹ sư phần mềm là những người được đào tạo, sáng tạo và chuyên nghiệp — nhốt họ trong “lồng sắt” thì thật vô lý. Họ cần một quy trình giúp họ giang cánh, không phải bị giam cầm. Chúng ta cần kiểu làm việc "nuôi thả tự do" (free-range) chứ không phải "nuôi nhốt công nghiệp" (battery).

Buồn thay, nhiều lập trình viên thậm chí không biết là mình đang sống kiểu đó — họ nghĩ làm việc quá giờ và dự án thất bại là chuyện… đương nhiên.

Stand-ups và Sprints không tạo nên Agile

Tôi đang mượn lời của Aristotle (chứ không phải Yoda), ý tôi là: quá nhiều nhóm chỉ dựng lên một cái vỏ bọc Agile để che giấu thực tế bên trong, nhưng ngay cả cái vỏ đó cũng tệ. Việc thực hiện daily stand-up thiếu hiệu quả và quản lý sprint một cách hời hợt không biến bạn thành Agile, mà biến bạn thành Badgile.

Có rất nhiều lý do khiến các nhóm không thể thiết lập quy trình Agile hiệu quả:

• Thiếu hiểu biết (Lack of understanding)
• Ban lãnh đạo không ủng hộ (No buy-in from executives)
• Nhóm không ủng hộ (No buy-in from the team)
• Thiếu lòng tin vào nhóm (Lack of trust)
• Sợ thay đổi (Fear of change)
• Thờ ơ (Apathy)

Và còn hàng triệu lý do khác. Nhưng điều tồi tệ hơn cả thất bại khi cố áp dụng Agile, là giả vờ áp dụng bằng cách nhét stand-up và sprint vào một nhóm, rồi tuyên bố “chúng tôi đã đạt đến đỉnh cao Agile”, và không bao giờ nhìn lại quy trình đó nữa.

Trong nhiều trường hợp, bạn sẽ làm tốt hơn nếu áp dụng đúng Waterfall thay vì theo kiểu Franken-Agile (một quy trình “quái vật” chắp vá), nơi quy trình đáng lẽ giúp bạn xây dựng phần mềm tốt hơn lại trở thành nghi thức hình thức không mang lại giá trị.

Nếu bạn không đánh giá và cải tiến quy trình, bạn đang sống như “xác sống” (walking dead)

Nếu bạn may mắn, một ngày nào đó bạn sẽ “tỉnh giấc” và tự hỏi: “Mình đang làm cái quái gì vậy?”. Hãy chất vấn và phân tích tất cả, đặc biệt là các bước của Scrum. Scrum là điểm xuất phát — là nơi tốt để bắt đầu hành trình Agile. Nó cung cấp những “lan can an toàn” (guardrails), nhưng nếu sau một năm quy trình của bạn vẫn y nguyên, thì rất có thể bạn không phải đang làm Agile.

Nếu mọi nhóm đều làm y hệt nhau, bạn không Agile. Ưu tiên thay đổi, tổ chức thay đổi, công nghệ thay đổi — và vì vậy quy trình cũng phải thay đổi.

Không có quy trình hoàn hảo

Tôi không nói mình là “thiên tài quy trình” (để người khác đánh giá), nhưng nếu bạn muốn thành công, bạn phải cố gắng thật sự. Nhiều người thích nói mình theo Agile vì nghe “ngầu” hơn nói mình thích Waterfall. Nhưng bạn không thể trở thành The Fonz chỉ vì mặc áo khoác da — trong phép ẩn dụ này, stand-up và sprint là áo khoác da, còn Agile là The Fonz.

Nếu bạn thấy mình đang làm Badgile, dù lý do là gì, bạn có thể thay đổi. Sẽ khó, sẽ có nhiều thử thách, nhưng hãy cố gắng — vì chính bạn, vì tổ chức của bạn, vì cả nhóm của bạn.

Hãy học hỏi, bắt đầu từ Scrum, nhưng phải thực sự bắt đầu từ nó — hiểu triết lý đằng sau, đừng chỉ làm theo nghi lễ (ceremonies). Nếu gặp phản đối, hãy giáo dục người xung quanh. Bạn không phải là kẻ lập dị đang cố áp đặt một quy trình “hippy” — bạn đang đi theo bước chân của những công ty phần mềm hàng đầu thế giới.

Và nếu bạn cố hết sức mà vẫn không thể thay đổi môi trường đó, hãy tìm nơi nào cho phép bạn vươn cánh và thể hiện năng lực thật sự — một nơi có văn hóa tin tưởng và tự do.

Tôi hứa, nó sẽ tốt hơn nhiều!

Link bài viết gốc (tác giả James Willis)