Xin chào các bạn.

Lý do có bài viết này là vì mình lướt 1 group về Agile ở VN và thấy bài viết của 1 ông nào đó ở Twitter nói về việc Scrum không hiệu quả. Tò mò đọc xem thì cũng thấy có gì đó sai sai.

Thế nên mình viết bài này để hít hà drama Và cũng bẻ cả 1 loạt xem rốt cục ở đây các ông đã hiểu Scrum sai ở đâu.

(Mình sẽ không chia sẻ Twitter chứa bài viết gốc bởi có dấu hiệu truyền thông bẩn của tác giả vì ngoài bài này ra các bài còn lại là đi PR khoá học ML. Các bạn có thể tự tra bài viết gốc dựa vào thông tin mình đưa bên dưới)

Bài Twitter kia tóm tắt gì về Scrum?

Đây là nội dung tóm gọn lại vì sao ổng bảo Scrum là vô dụng:

Some anecdotes:

1. They tried to convince me that Poker is a planning tool, not a game.

2. If you want to be more efficient, you must add process, not remove it. They had us attending the "ceremonies," a fancy name for a buttload of meetings: stand-ups, groomings, planning, retrospectives, and Scrum of Scrums. We spent more time talking than doing.

3. We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.

4. We spent more time estimating story points than writing software. Story points measure complexity, not time, but we had to decide how many story points fit in a sprint.

5. I had to use t-shirt sizes to estimate software.

6. We measured how much it cost to deliver one story point and then wrote contracts where clients paid for a package of "500 story points."

7. Management lost it when they found that 500 story points in one project weren't the same as 500 story points on another project. We had many meetings to fix this.

8. Imagine having a manager, a scrum master, a product owner, and a tech lead. You had to answer to all of them and none simultaneously.

9. We paid people who told us whether we were "burning down points" fast enough. Weren't story points about complexity instead of time? Never mind.

Ôi đùa, tận 9 mục như này thì bài mình dài vãi... thôi thì chịu khó ngồi bẻ từng mục vậy.

Mục 1: Planning Poker

Planning Poker là cách để est độ khó hoặc thời gian thực hiện 1 task tuỳ theo quy chuẩn của team hoặc tổ chức. Nếu trong lúc quản lý dự án với sprint planning mà đánh số cho ticket không kể độ phức tạp, thời gian thực hiện thì đây là chơi Poker chứ không phải phương pháp Planning Poker.

Mục 2: Individuals and interactions over processes and tools

Mình đặt tên mục như này vì nó đang bị hiểu sai. Scrum không loại bỏ các process mà ngược lại, cần có các process để team có thể chung 1 phương pháp giao tiếp nội bộ. Nhưng nếu quá nhiều process và process không hiệu quả thì phải bỏ đi.

stand-ups, groomings, planning, retrospectives, and Scrum of Scrums

Tất cả các thuật ngữ trên đều không tồn tại ở Scrum Guide nhé. Scrum chỉ có 4 loại meeting:

• Daily Meeting
• Sprint Planning
• Sprint Review
• Sprint Retrospective

Và kể cả scaled-Scrum biến thể thì cũng không có cái Scrum of Scrums meeting. Chỉ tồn tại thêm 1 daily meeting cho nhiều Scrum team. Và các event này phải được time-box để tốn ít thời gian nhất có thể để không xảy ra hiện tượng:

We spent more time talking than doing.

Thế nên hiện tượng này chứng tỏ các meeting cũng không hiệu quả, tốn thời gian.

Mục 3: Passing ball

Daily Scrum không cấm dùng laptop, không cấm ngồi và cũng không có trò truyền bóng. Cái này do công ty ông với Scrum Master của team ông làm ra chứ không có liên quan gì tới Scrum cả.

Mục đích của Daily Scrum/Daily Meeting là để cho dev có thể trước hết là tự báo cáo tiến độ công việc của mình cho chính mình, sau đó là cho team(thực tế có cả PM/PO của dự án). Cái ở đây cần là tiến độ task tới đâu chứ không phải meeting như nào. Nên ít nhất trong 3 hiện tượng trên, việc không được tiếp xúc với laptop có thể dẫn đến hiện trạng khó track được luôn task mình đang xử lý ở trạng thái sao, và phải áp dụng truyền bóng chứng tỏ team đang có vấn đề tương tác cũng như thái độ làm việc.

Mục này cũng đang mâu thuẫn mục 2: team này đang bỏ đi các quy trình nhưng với Daily Meeting thì thực hiện 1 cái quy trình mà không thấy 1 cái hiệu quả nào cả.

Tiện thì mình có thể sẽ thêm vụ này vào bài bên dưới của mình về Daily Meeting.

Mục 4: Story points hơn software

OK, câu story points là đo độ phức tạp có phần đúng nhưng chưa đủ. Có những lúc story point sẽ đóng vai trò như value point để đánh giá độ quan trọng của task(tuỳ định nghĩa từng team).

Và nhét bao nhiêu story point trong 1 sprint cũng như dùng story point để tính time? Mình không ý kiến việc dùng để tính time(thường cái này Sprint point sẽ có hữu dụng hơn), nhưng tính là 1 sprint cần bao nhiêu point để nhét vào thì cái team này định làm cho đủ số giờ hay là không có gan để OT nhằm hoàn thiện sản phẩm vậy? Theo định nghĩa team này và tính toán thì các Sprint không nhất thiết phải cùng 1 số lượng Story point. Thế nên khi có tính năng cần gấp, số points cao vống lên thì dev sợ overtime à? Khi product ổn định ít task thì manager sợ hiệu quả công việc đi xuống chăng?

Mục 5: T-shirt size để đánh giá task

Ông dùng T-shirt size kệ ông, miễn là ông làm được việc. Nhưng làm 1 bộ quy đổi để sao cho fit với team đi chứ đừng có ngồi than.

Mục 6: Hợp đồng 500 points?

Nếu tôi là khách hàng thì tôi không hiểu 500 points đó có ý nghĩa gì. Cái tôi quan tâm là sản phẩm tôi đặt tính năng như nào mà giá như thế. Còn lại 500 points kia là việc của phía đội phát triển tôi không quan tâm. Khi thương thuyết với khách hàng và đưa ra khái niệm trừu tượng mơ hồ thế thì tư duy quản lý có vấn đề.

Mục 7: 500 points bên này khác bên kia

Các phần mềm khác nhau thì độ phức tạp, thời gian làm và cách est khác nhau. Giờ đánh đồng là product nào cũng độ khó như nhau với số điểm như nhau như vậy cũng vô nghĩa. Nó không phục vụ gì cho sản phẩm cả.

Mục 8: Báo cáo cho tận 4 người

Ở trong Scrum thì không có ông Manager và ông Tech Lead. Và bản thân định nghĩa Scrum thì Scrum Master sẽ không động vào các Sprint Backlog Item nên Dev chỉ có nghĩa vụ báo cáo tiến độ cho các thành viên khác trong team cũng như Product Owner.

Còn thực tế thì nhiều khi 4 role là 1 ông thì chỉ cần báo cáo cho ông đó là đúng rồi. Kể cả phải báo cáo 4 người thì chả lẽ các ông không có cải tiến gì để 4 ông cùng nhận được thông tin mà chỉ báo cáo 1 lần? Và nếu theo đúng quản lý thì tiến độ công việc ông PM và ông PO đáng để báo cáo chứ ông Techlead và ông SM báo cáo để làm gì?

Mục 9: Burning down point?

Đúng là burn-down chart cũng là 1 tool khá hiệu quả, nhưng dùng để đếm số task/số item trong 1 sprint, chứ không phải số Story/Value/Sprint point giảm dần theo thời gian. 1 item 10 point và 10 item 1 point khi biểu diễn ở burn-down chart sẽ khác nhau về số item và số point, nhưng liệu bạn muốn đếm số task/item tương ứng với số tính năng/bug được fix trong sprint hay số point đã hoàn thành trong sprint hơn?

Mục bonus:

Sau khi bẻ hết các điều trên thì mình nhận ra chả có cái nào dính đến những giá trị cơ bản ở Scrum Guide cả. Đây là 1 hổ lốn các practice của Agile được bốc cái này bốc cái nọ để gọi là Scrum. Team trong bài cũng là 1 team coi trọng việc quản lý với làm màu hơn là làm phần mềm, đồng thời tác giả cũng chả biết gì về Agile cũng như các phương pháp quản lý dự án và team.

Kết luận

Tưởng bài viết dài nhưng thực ra thì nó chả động đến khái niệm Scrum và Scrum Guide nhiều, đã thế còn ra 1 mớ practice Agile bị áp dụng máy móc.

Dù sao thì qua bài này, mình mong muốn là mọi người sẽ hiểu đúng Agile, chịu khó tìm hiểu về Scrum bài bản và đừng quản lý dự án bằng các phương pháp nghe rất hiện đại, tạo những số liệu với thước đo nghe rất kêu để tạo ra 1 dự án nghe rất kêu nhưng không phục vụ gì cho chất lượng của sản phẩm deliver với những báo cáo về những khái niệm trừu tượng không liên quan tới kq cuối cùng của sản phẩm.

Cảm ơn mọi người đã đọc bài này của mình.