Trong quá trình làm việc với team trong Scrum, đã bao giờ bạn gặp phải trường hợp tương tự thế này chưa? Task A làm rồi, task B này chỉ cần bê nguyên giao diện của task A sang rồi thêm cái lọ, cái chai vào là xong thôi, giảm một nửa điểm đi.
Thoạt nhìn thì thật đơn giản và có vẻ đúng. Nhưng khi các bạn thực hiện theo đúng phương án này thì thời gian cho task B không hiểu sao lại cứ tăng lên, và chẳng có vẻ gì là nó đáng để giảm đi một nửa điểm cả.
Hãy cùng nhìn lại để xem chuyên gì đã xảy ra nhé:
Vấn đề cơ bản nhất ở đây chính là task A cũng nằm trong sprint này. Có nghĩa là ngoại trừ khi bạn là siêu nhân, nếu không thì điều đó có nghĩa là tại thời điểm bạn làm task B, task A hoàn toàn chưa được test kỹ cẩn thận. Vẫn còn đó những case ẩn, những ngóc ngách mà khi bạn estimate vẫn chưa dự đoán được hết.
Và dĩ nhiên khi đó thay vì chỉ tốn 50% thời gian để làm task B như dự đoán thì bạn lại phải tốn thêm thời gian để triển khai một logic, hay sửa một cái bug nào đó trên cả hai task này.
Thời gian của bạn dĩ nhiên là cũng sẽ tăng lên đáng kể, hoàn toàn không như bạn mong muốn.
Như vậy điều chúng ta cần rút ra ở đây là gì ? Đó là sự khác biệt giữa dự tính và thực tế. Thực tế rõ ràng thì không lúc nào màu hồng như bạn muốn. Nếu bạn chưa phải là siêu nhân có thể estimate chuẩn khét lèn lẹt tất cả các trường hợp có thể xảy ra, bạn nên có kế hoạch tốt hơn để tránh rơi vào trường hợp này.
Vậy bạn cần phải làm gì ?
Khi có yêu cầu như trên, bạn nên xem xét tách task B sang sprint tiếp theo. Khi đó task A đã được hoàn thành và test kỹ lưỡng bởi đội tester. Rủi ro cho bạn rõ ràng là sẽ giảm đi phân nửa.
No comments:
Post a Comment