Agile thực chiến – Part XX
Add Tester vào Scrum Team, vấn đề và thách thức
Vậy là giai đoạn migration code đã hoàn tất – nhẹ nhõm làm sao. Giờ là cuộc chiến tiếp theo: phát triển các tính năng mới và “tút tát” lại các chức năng hiện có.
Câu hỏi lớn nhất được đặt ra lúc này là: làm sao để cải thiện chất lượng, để sản phẩm đầu ra không thành bãi chiến trường, hoặc để ít nhất mỗi lần release không biên thành một cuộc phiêu lưu, một sự chờ đợi feedback trong sự run sợ.
Phân biệt chủng tộc
Tôi để title thế để gây chú ý thôi. Nhưng có một sự thật mà anh em trong ngành hầu như ai cũng gật gù công nhận với tôi: đó là tư duy phân biệt Developer và Tester. Theo tôi, gốc rễ của câu chuyện này bắt đầu ngay từ ghế nhà trường. Hệ thống giáo dục của chúng ta đang tạo ra các “thợ code” và “thợ test” chứ không phải là những Software Engineers đúng nghĩa (ít nhất là theo quan điểm cá nhân tôi). Một Software Engineer thực thụ theo tôi phải là người biết lên kế hoạch, viết code, viết unit test, tự thực hiện kiểm thử để đảm bảo mỗi dòng code mình tạo ra đều đạt chất lượng và tâm đắc với mỗi dòng code đó.
Trong một dự án, nếu một anh developer được giao nhiệm vụ test, dù là test chính những dòng code mình viết ra, thì thường sẽ xuất hiện một cảm giác rất…lạ. Kiểu như: “Ủa, mình là developer cơ mà, sạo lại đi làm tester thế này?”. Và rồi cảm giác như mình bị đánh giá thấp, cảm thấy không còn được trọng dụng nữa. Thế là, vừa test code, anh ta vừa âm thầm mở trang tuyển dụng, âm thầm cập nhật CV – phòng khi cần… nhảy việc gấp.
Biết làm sao?
Anh em trong ngành IT thì có tâm lý “Phân biệt chủng tộc” giữa Developer và Tester thì ai cũng quá quen rồi. Nhưng biết sao giờ, cuộc sống mà – vẫn phải “sống chung với lũ” và tìm cách hợp tác thôi.
Cũng chính vì đặc điểm đó, mà việc thêm Tester vào Scrum Team với chức năng cụ thể là viết test và thực hiện test quả thật là một thử thách không hề nhỏ. Thách thức về mặt lên kế hoạch, thách thức cả trong giao tiếp và cả trong việc giữ hoà khí trong Team.
Tôi sẽ đi sâu vào từng thách thức, cách tôi đối mặt với chúng. Có thể đó chưa phải là những giải pháp tối ưu nhất, nhưng ít nhất nó chạy được. Đối với dân IT chúng ta, “chạy được” đã là một thành công rồi, phải không?
A caption for the above image.
Designed A Fun And Dynamic Hackout
Lên kế hoạch Sprint
Nếu một Scrum Team mà tất cả thành viên đều làm việc như những Software Engineers “chuẩn chỉnh” — biết lập kế hoạch, code, viết unit test, tự test và đảm bảo chất lượng đầu ra — thì việc lập kế hoạch cho Sprint sẽ trở nên đơn giản và nhẹ nhàng biết bao. Nhưng đời không như là mơ! Với tất cả những vấn đề tôi đã nhắc đến ở trên, để làm được điều đó — ít nhất là ở Việt Nam — đúng là… thử thách to lớn.
Nếu mọi thành viên đều có thể tự hoàn thành một backlog item từ A đến Z, thì chuyện lập kế hoạch đơn giản hơn nhiều: ai cũng chỉ cần dựa vào Velocity cá nhân mà chọn số lượng backlog item phù hợp.
Nhưng với thực tế hiện tại — nơi developer và tester mỗi người chỉ phụ trách một phần việc khác nhau trong cùng một backlog item — thì việc lập kế hoạch phức tạp hơn nhiều. Chúng ta phải cân bằng giữa Velocity cá nhân và Velocity của cả team (thường là đã được cam kết), làm sao để mọi thứ khớp với nhau mà không ai phải “ngồi chơi xơi nước” hoặc chạy deadline đến… bốc khói.
Một ví dụ đơn giản cho các anh em có thể hình dung. Trong Sprint 2 tuần, với 6 thành viên, chúng ta thực hiện khoảng 36 story point (pt) bao gồm 3 backlog items 13pt. Chúng ta sẽ lên kế hoạch cho 1 backlog item.
| Task | Người thực hiện | Số ngày để hoàn thành |
| Implement | Dev | 2 |
| Unit Test | Dev | 1 |
| Viết test case | Tester | 3 |
| Thực hiện test | Tester | 2 |
Nhìn vào bảng trên, bạn sẽ thấy một tình trạng khá “tréo ngoe”: trong 2 ngày Tester “hì hục” thực hiện test, Dev lại rơi vào trạng thái… ngồi rung đùi, chờ xem có bug không để fix. Rõ ràng, đây là một sự lãng phí nguồn lực — việc quản lý nhân sự như thế này thực sự chưa hiệu quả chút nào.
Bạn có thể nghĩ: “À, đơn giản thôi! Trong lúc Tester đang test, Dev cứ làm tiếp PBI (Product Backlog Item) tiếp theo là được mà!” Nghe có vẻ hợp lý, nhưng đó chỉ là giải pháp tạm thời — và vấn đề sẽ bộc lộ ngay ở các PBI kế tiếp.
Giả sử một Sprint kéo dài 2 tuần với 10 ngày làm việc. Nếu Dev cứ tiếp tục “cày” hết tốc lực, thì trong 6 ngày đã hoàn thành xong 3 PBI. Trong khi đó, Tester vẫn đang loay hoay hoàn thành việc test cho… PBI thứ 2. Kết quả? Dev rảnh rỗi chờ bug, Tester ngập trong backlog — và cả team thì lệch nhịp hoàn toàn. Thế nên, bài toán phân bổ công việc không đơn giản như ta tưởng đâu!
Bởi vậy cần phải lên kế hoạch ngay từ đầu tương quan tỷ lệ số thành viên giữa công việc test và công việc DEV dựa trên đặc thù công việc, đặc thù các PBI, số tương quan giữa nguồn lực cần thiết.
Mr.Tre
Cần làm gì khi đã lên kế hoạch tương quan Dev, Test rồi mà vẫn xảy ra tình trạng Planning bị lệch như trên?
Khi chúng ta đã cố gắng hết sức để cân bằng nguồn lực giữa Dev và Test mà vẫn xảy ra tình trạng lệch nhịp “tréo ngoe” như trên, thì… đến nước này, đành phải “điều quân” Dev sang hỗ trợ Test thôi!
Tất nhiên, việc nhờ Dev tham gia một phần nhỏ công việc của Tester chắc cũng không đến mức khiến các anh em Dev cảm thấy tổn thương lòng tự tôn nghề nghiệp, rồi lại âm thầm mở LinkedIn cập nhật CV như cái cảnh tôi đã nhắc đến ở trên. Chỉ cần khéo léo phân chia nhiệm vụ, giúp Dev thấy đây là chuyện “hợp tác vì đại cuộc” chứ không phải “lấn sân”, thì mọi chuyện sẽ ổn thôi — ít nhất là tôi hy vọng thế!
