Một trong những điều được bàn luận nhiều nhất trong thời gian vừa qua của team mà mình nghe được đó chính là cách vận hành không theo chuẩn "agile". Với một "tay mơ" khi đụng nhắc đến quy trình của Scrum thì mình tiếp thu được khá nhiều điều thú vị.
Note một chút, đây là một team nước ngoài, và mình đã làm trực tiếp với họ, nên có thể cách suy nghĩ sẽ khác một chút. Bài viết này chỉ chia sẻ lại những gì mình đã được nghe và cũng như tìm hiểu được.
Epic, Milestone và Deadline
Một trong những ý tưởng lớn nhất khi làm việc theo Agile đó chính là thích nghi với thay đổi. Đây là một trong những cái mà đồng nghiệp của mình cho rằng chính những milestone và deadline đang tác động đến công việc của team.
Nói sơ một chút về trường hợp chỗ này, một yêu cầu của người dùng có thể được tính là một Epic (tạm hiểu: một tính năng lớn), trong đó có nhiều stories khác nhau được cân đo đong đếm bởi development team. Trong một Epic lớn, có thể có nhiều epic nhỏ, chia thành những milestones và mỗi milestone lại có một thời gian thực thi khác nhau.
Mặc dù việc lên kế hoạch rõ ràng có thể giúp dự án có một hướng đi rõ ràng trong từng giai đoạn, tuy nhiên, do tính chất liên tục thay đổi của một dự án, mặc dù có thể đã được lên kế hoạch từ trước vẫn sẽ có những sai lệch. Việc này sẽ vô tình sẽ đẩy những deadline của dự ra xa khỏi dự tính ban đầu của những người làm về business. Tạo một áp lực vô hình lên nhóm phát triển phải đẩy nhanh tiến độ, bằng mọi cách tăng tốc để đạt được "deadline".
Commitment
Với mình 100% sprint commmitment luôn là mục tiêu mà team luôn hướng tới. Tuy nhiên, các thành viên trong team mình đã nói rằng:
- Nếu mình luôn commit được 100% sprint, thì có nghĩa là mình đang có khả năng làm thêm công việc.
- Với mỗi thời gian, giai đoạn khác nhau trong sprint "capacity" (tạm dịch: khả năng làm việc) sẽ có sự thay đổi khác nhau. Chúng ta sẽ không thể liên tục đảm bảo luôn hoàn thành lượng công việc cố định (ví dụ: 13 points/sprint)
Trong một bài viết của từ Scrum.org - Commitment vs Forecast cũng đã chỉ ra rằng sử dụng từ "commit" sẽ thường bị hiểu nhầm thành một công việc bắt buộc phải hoàn thành, và điều này lại không phù hợp với tính chất của Agile.
It is not uncommon (or unreasonable, frankly) for people on the business side to hear that the Development Team has committed to deliver a list of Product Backlog Items and take it literally. They expect to have every single item delivered at the end of the Sprint, at any price. And, what is even worse, they begin making plans, assumptions and decisions based on this not yet confirmed fact. Then, if the commitment is not fulfilled, they may try to “claim their guarantee”, and ask for liable individuals.
Các anh chị trong team cũng cho rằng "forecast" sẽ là từ hợp lý hơn khi nó sẽ cần dựa trên số liệu của các sprint trước, và thời gian sắp tới.
The Development Team is pushed under the wrong kind of pressure, and the team members find themselves struggling to deliver each and every one of the selected Product Backlog Items by means of rushing, taking shortcuts, accumulating technical debt and not fulfilling the Definition of Done.
Technical debt (tạm dịch: chạy được trước rồi sửa sau) có lẽ là một trong những điều mình thường xuyên gặp nhất của những dự án đang bị "chậm tiến độ", khi nhóm phát triển được "cổ vũ" để hoàn thành tất cả các stories để kịp tiến độ, thay vì tập trung vào việc giải quyết tốt các vấn đề trong các stories hiện có, để đảm bảo chất lượng đầu ra.
Lời kết và đôi lời
Theo góc nhìn của cá nhân, mình nghĩ mọi công việc luôn nên có một thời gian định trước cụ thể. Tuy nhiên, để luôn bám theo kế hoạch mà không có sự xê dịch thì mình thấy điều này tương đối gây khó khăn cho các development team, vì theo Agile: khối lượng công việc chỉ là dự báo dựa trên nhiều yếu tố khác nhau và không thể chính xác 100%.
Việc chạy theo kết quả mà bỏ qua sức lực của team và team capacity trong từng khoảng thời gian sẽ có thể gây tác động lâu dài (cộng dồn) từ code base đến con người tham gia vào quá trinh phát triển phần mềm. Đặc biệt là trong các công ty outsource, khi hợp đồng được ký dựa trên một mốc thời gian cụ thể.
Bạn thấy thế nào? Bạn đã từng phải chạy như vậy chưa?
P/s: Mình không phải là một Scrum Master.