Một số hiểu lầm về Scrum

Bài viết mang đặc góc độ quan điểm cá nhân của tác giả. Có thể người đọc không hiểu lầm gì cả nhưng dưới đây tôi chỉ rảnh rang ngồi kể lại một số suy nghĩ và góc nhìn của mình về Scrum thôi. Sau đó nhận gạch đá cho vui.

Cảm quan của tôi đầu tiên về Scrum là giống Thiền hoặc Khí công, rất dễ làm, yêu cầu đều đặn không cao, ấy vậy mà có ông thì thiền thấy thư thái an lạc, có ông thì cũng hít vào thở ra, cũng y hệt … mà chả thấy an lạc ở cái mốc xì nào. Cũng khua tay khua chân giống sách mà chả thấy khí đâu cả.

Rồi thì làm mãi chả được gì thì chán, có khi quay lại chửi, có khi bảo không phù hợp .v..v. cũng có đôi khi người ta không hiểu nên nói quá nó lên là một thứ gì đó kì diệu xong lại vỡ mộng.

Scrum để làm gì?

Hôm trước anh Thắng post trên launch là startup thì cần Scrum, sau bị gạch đá chửi tơi bời “startup cần quái gì quy trình, startup là nhanh xong run” … ờ thì tôi cũng đồng ý là quan điểm đó, nhưng thấy rằng có thì nó tốt hơn về lâu về dài. Còn tại sao thì tôi xin giải thích ở sau đây.

Lợi ích mà Scrum với Agile thì sách vở slide nói nhiều rồi, nhiều người nói là delivery sản phẩm nhanh hơn, rồi đủ thứ … nhưng tôi thấy thứ được nhiều nhất đó là : các thành viên tham gia vào dự án giỏi lên, chủ động hơn. Đỡ mất tiền cử đi đào tạo, sau này có toàn người năng động. Dream team cmnr.

Cái này khá có giá trị nếu đầu tư đường dài, đấy cứ giả sử bạn có một team sau một thời gian làm “đối thủ vừa làm tính năng A, team xem thế nào chúng ta có 2 tuần, chúng ta phải làm cái B đập chết nó cho tôi, tôi cần nó có cái này cái này cái này…” team làm rầm rầm 2 tuần sau có bấm nút chạy phà phà trong khi vẫn rung đùi, chả phải phó mặc cho một ông phân tích thiết kế tam sao thất bản, rồi lại dev gãi đầu gãi tai chả hiểu cái này là cái gì bảo thì làm loằng ngoằng dẫm chân nhau mãi chả xong. Nghe có vẻ sướng.

Còn nếu cần gấp, làm xong việc thì không nên dùng Scrum hoặc không cần sáng tạo gì cả thì nên đóng khung và làm theo đúng quy trình.

Scrum theo tôi nó có ý nghĩa phát triển con người hơn là mấy cái lợi ích kia.

Bóng đá và đóng gạch

Để ví dụ về Scrum tôi thích nghĩ rằng giống như bạn đang làm huấn luận viên của đội bóng đá. Trước đây các quy trình công nghiệp giống như đóng gạch, cứ đến chỗ này rồi ông kia làm việc này việc kia. Nhưng đá bóng thì chẳng có trận nào theo đúng quy trình cả, ông bầu hay huấn luận viên nào vẽ được ra quy trình đưa bóng vào gôn của đối phương như lên góc này thì sẽ thế này, xuống đây thì sẽ đi qua cái này rồi sang cái này là tới đích. Chúng ta cần sự linh hoạt (Agile) tự đối phó các tình huống từ chính bản thân các cầu thủ chỉ giúp cho các bé chân gỗ level huyện thành tuyển thủ quốc gia\quốc tế bằng cách nâng trình độ của nó lên chứ còn làm sao để sút vào gôn ngoại trừ driven chiến thuật thì đấy là việc của nó và việc của team nó.

Thì Scrum cũng như vậy, công việc của Product Owner (PO) là xác định gôn đâu để sút, ScrumMaster (SM) làm sao cho team ngon lên đá trình Ngoại hạng Anh chứ không phải là cứ mãi ở trình thôn xóm. Thấy quân đá ngu không được phép sốt ruột nhảy vào đá hộ (trọng tài đuổi ra) thì đấy là lí do ScrumMaster không bao giờ được code hộ developer, mà chỉ được hướng dẫn code thế này, đá má thế này, hoặc không dạy được đá thế nào thì phải hỗ trợ tìm người giúp nó biết đá.

Nhiều người hay lẫn lộn ScrumMaster với sếp, trưởng phòng, hoặc Leader v.v… Vậy thì lão ScrumMaster làm cái khỉ gì đây mà phải trả tiền cho lão ? “ScrumMaster là người đảm bảo tất cả các thành viên làm theo đúng Scrum ?” Không đủ. Có người bảo ScrumMaster là cave, là supporter của team . Vẫn không đủ. Theo tôi nên dịch từ Master ở đây là “SƯ PHỤ” chứ không phải là “Sếp” – một người am hiểu sâu về Scrum và có thể giúp team hoạt động có hiệu quả tốt. Ông ta không chịu trách nhiệm khi fail dự án, không làm các công việc như điều phối công việc, v..v…ông ta chỉ chịu trách nhiệm nếu team của ông ta không có kết quả cao khi không làm đúng Scrum hoặc ông ta chưa làm đúng Scrum.

Vậy nếu dự án fail thì ai phải chịu trách nhiệm ? Vậy theo bạn nếu một đội bóng không đạt giải thì ai sẽ đứng ra chịu trách nhiệm ? Huấn luận viên ? Tiền đạo (dev) ? Thủ môn (tester)? Ông bầu ? …

Vậy nên khi làm theo Scrum, được thì ăn cả, mất thì phải chết cả làng, bạn không thể chơi mãi lối chơi cá nhân được bắt buộc thành viên trong team phải giúp nhau. Thế nó mới đau, đang bận bỏ mẹ ra cũng phải giúp thằng bên cạnh. Nên tôi nghĩ muốn làm Scrum thì nếu fail dự án phải sa thải cả team hoặc phạt cả team, chơi solo thì bản thân cái Scrum thất bại. Vì sau này sẽ chả ai giúp ai cả nữa vì còn bận lo việc mình.

Daily Meeting

Ngày nào cũng phải họp, ngày nào cũng phải đứng trước bảng để trả lời 3 câu hỏi ngớ ngẩn vcđ, hôm qua làm gì, hôm nay sẽ làm gì, có gì khó khăn không?
“Ngán bỏ mẹ, xong lại còn hôm qua không làm gì biết báo cáo gì đây, khó khăn nói ra có khi lại bị đánh giá kém, thôi em là em tự tìm được tại sao, ông muốn thanh tra tôi xem hôm qua chứ gì, bạn gái bỏ rồi, lòng dạ đ’ đâu mà code, tôi là tôi bỏ mẹ cả cái công ty ấy chứ cần gì tiền”.

Công ty tôi vì tôi khi đó vừa làm CEO bận đi gặp khách hàng hôm đến công ty hôm không, vừa đóng vai trò ScrumMaster, nhà lại sẵn dev đã code hẳn một chương trình daily report có 3 câu hỏi, code hẳn mục comment và notification vào để tối về tôi xem lại rồi skype hỏi. Nhưng đúng là thanh tra nhưng hoá ra đấy không phải cái tinh tuý của Scrum, fail lòi.

Tôi sẽ lấy một ví dụ nhỏ, bản thân tôi nghiệm thấy rằng Daily Meeting hay ở chỗ không phải để báo cáo mà là face to face, thằng cu này nó trả lời đúng nhưng sắc mặt có vẻ không ổn (mà cái này viết bằng text xong làm sao mà biết được), chính xác lúc đó là thanh tra nhưng bạn làm gì với cái thanh tra đó không phải là ScrumMaster hỏi dồn kỹ càng về công việc các thứ, mà để ScrumMaster sau đó “à, thằng này có vấn đề” thủ thỉ đến bên hỏi “sao hôm nay đá kém thế – sao nay code kém thế” lại thủ thỉ nhà có việc hoặc bồ đá v.v… Đấy vấn đề là quản trị con người nó khó hơn phần mềm là con người ảnh hưởng bởi rất nhiều tham số, ScrumMaster cần tìm ra cái tham số ảnh hưởng đó và hỗ trợ nó chỉnh sửa ví dụ như :

– Tối qua nhà anh giới thiệu em này xinh lắm, dạy đời nó về gái gú, chia sẻ anh cũng bị gái sút ra sao.

– Tối sang nhà anh mua dầu ăn cho.

Cho nó nghỉ mấy hôm vì biết thằng này có làm tiếp cũng không hiệu quả, bàn lại với PO hoặc đưa ra cách thức xử lý cần thiết. Đấy, ScrumMaster (SM) rất cần sự tinh tế và thanh tra cái “luôn luôn lắng nghe, lâu lâu sẽ hiểu”. SM cần xử lý về sự vận hành ổn định của team tâm lý lẫn các vấn đề thực tế qua các buổi nói chuyện.

Ngoài ra có nhiều việc rất cần thiết kỷ luật như ngày nào cũng phải Daily Meeting, thông não cho thành viên tại sao phải Daily Meeting v.v.. Tóm cái váy lại là làm sao cho team hiểu và làm tốt Scrum chơi phối hợp nhịp nhàng chiến thắng trên các trận.

Product Owner (PO)

Ban đầu tôi chỉ nghĩ Product Owner là thằng nắm giữ và đưa ra các hạng mục Product Backlog thôi, ví dụ anh cần xây cái nhà vệ sinh, cần xây cái toa lét, cần trong nhà tắm có thể xem được video … hoá ra nhiều việc hơn tôi tưởng.

… Mỏi tay quá

Còn Burndown Chart
Còn Glad Mad Sad
Còn Poker …
Lean Coffee
Còn team vote
Timebox để làm cái gì (cái này hay vãi chưởng)

Thôi để viết tiếp sau, tôi thấy Scrum toàn ba cái cách quản lý con người khôn ngoan vãi chứ không phải là cái quy trình phần mềm nữa. =.=

P/S : Phải công nhận là hôm trước đi học conference cùng được với toàn các anh tài cùng bàn thế nên mới vỡ lẽ ra nhiều điều. Mỗi người làm công việc thảo luận trên chính Scrum lại càng thấy nhiều cái hay của nó. Về nhà mà cũng “không được yên” :v

FB. Dương Viết Cường