Vài vấn đề về deadline trong SCRUM's Sprint

Chúng ta đều biết rằng deadline sẽ điều khiển hành vi. Đó là lý do tại sao trong Scrum, và các phương pháp Agile khác, chúng ta timebox việc phát triển với những deadline (Sprint). Nó sẽ chỉ rõ cho chúng ta: Tập trung vào những thứ quan trọng và đảm bảo rằng nó được thực hiện đúng. Về bản chất điều đó là rất tốt, tuy nhiên giờ hãy xem chúng ta làm việc với deadline cẩu thả như thế nào Thường thì process sẽ là thế này: chúng ta chuẩn bị Sprint, tách user story thành task, sub-task và estimate. Sau tất cả nỗ lực này, chúng tôi quyết định start Sprint với những user story được chọn và chúng ta cam kết có thể deliver nó đúng hạn deadline.

ĐIỀU NGẠC NHIÊN Sự việc xảy ra. Chúng ta phát hiện ra nội dung mới, chi tiết ẩn mà lúc clarify task và estimate ko nhìn thấy. Chúng ta cũng phát hiện ra các task không có kế hoạch tràn vào. Deadline có vẻ không ổn. Chúng ta sẽ không thể kết thúc Sprint đúng deadline được...

Hãy tưởng tượng sự nhục nhã, xấu hổ kinh khủng khi không đáp ứng được chính estimation của chúng mình. Làm sao chúng ta có thể đối mặt với khách hàng của mình với kết quả Sprint đầu tiên là miss hoàn toàn DoD (Definition of Done) ? Họ sẽ nghĩ gì về chúng ta?

Vì vậy chúng ta cắt bớt những chỗ mà mình tự cho là "không cần thiết lắm" của task, của user story. Chúng ta bỏ qua unit test, bỏ qua luôn code review. Chúng ta cho rắng user story chỉ là một phần nhỏ, và không cần thiết lắm để xem lại design có hợp lý hay không. Chúng ta push code, và hi vọng rằng việc testing sẽ không xảy ra bất cứ con bug nào trước deadline. Và có lẽ chúng ta may mắn, và chúng ta có thể coi user story là "done".

Cool, chúng ta đã có đủ story points của mình cho Sprint hiện tại. Party time!

Trớ trêu thay, Agile luôn muốn: Cá nhân và tương tác thì hơn các quy trình và công cụ. Chúng ta ném quá trình ra ngoài cửa sổ để làm hài lòng mọi người (và bản thân).

Hệ số sợ hãi Vâng, đó là câu chuyện cũ về deadline cứ lăn trên mỗi chúng ta, lần nữa và lần nữa. Nhưng câu hỏi là tại sao chúng ta để cho nó xảy ra (giả sử rằng ở đây ko có một business deadline thực sự nào cả, chỉ là kết thúc Sprint, hoặc thậm chí là release feature) ?

• Deadline là đơn giản. Chúng dễ dàng hơn việc giải thích và hiểu hơn DoD rất nhiều.
• Deadline là khách quan, còn done là chủ quan
• Deadline thì luôn thấy được (hết Sprint thôi mà). Done thì không, chúng ta chỉ biết được khi nào một task/một user story done khi chúng được test (bởi testers hay users)
• Deadline là không thay đổi, còn done thì khác. Done có thể thay đổi, vì DoD phụ thuộc vào thời điểm, vào khách hàng, vào những ngữ cảnh khác nhau

Chúng ta cảm thấy thoải mái hơn với deadline vì chúng ta đã sống với nó suốt cả đời. Chúng ta cố gắng hết sức để tuân thủ, để đáp ứng nó, thường bằng cách giảm chất lượng. Chúng ta cảm thấy thỏa mái để ưu tiên deadline, thậm chí là ép buộc (bản thân hoặc người khác), deadline hơn là những thứ khác. Chúng ta lựa chọn hoặc là chất lượng hoặc việc done task, bất cứ giá nào, chúng ta sẽ chọn done task đúng deadline.

Và bây giờ, chúng ta có Scrum Master, người sẽ hạ những tiêu chuẩn về DoD xuống. Vì thế, khi chúng ta nhìn vào board của team, chúng ta thấy một product manager với vẻ mặt rất hài lòng. Anh ta sẽ bảo với chúng ta, " oke, bạn có thể làm code review sau". Mọi developer điều biết "later mean never" :v

Sự thay đổi của hành vi

Chúng ta thích nói về mindset, thế làm thế nào chúng ta có thể thay đổi nó theo một hướng tốt hơn. Đen thôi, tôi không thể thay đổi của bạn, bằng cách tải mindset v2.0 vào trong não của bạn ) Cách chúng ta thay đổi là làm thế nào chúng ta nhận thức được hành vi của người khác. Nếu đội ngũ management và teammates thay đổi hành vi của họ, đó cũng sẽ là một cơ hội tốt cho cả tôi. Cụ thể:

• Vâng, thật tốt khi bạn không đã không push code lên respository và mạo hiểm code của mọi người.
• Vâng, thật tuyệt khi bạn đợi đoạn code đó được review vì chúng tôi tìm thấy 2 bug có thể xuất hiện khi deploy.
• Vâng, thật tuyệt khi bạn đã viết unit tests cho code của mình vì bây giờ chúng tôi có thể chuyển sang các tính năng khác phụ thuộc vào tính năng của bạn mà không sợ làm lại.
• Không, không tốt vì bạn đã bỏ qua việc xem xét lại design bởi vì ngay bây giờ rằng chúng tôi cần dừng công việc của những người khác và cả của bạn lại. Chúng ta sẽ quay lại bảng vẽ, design này thực sự có vấn đề, nó ảnh hưởng đến bạn, đến cả team.
• Không, không tốt khi bạn bỏ qua automation test vì bây giờ chúng ta cần phải regression test bằng tay mỗi khi feature được deploy.
• Không, nó không sẵn sàng cho production trừ khi mọi người đồng ý rằng nó dựa trên những gì chúng ta ĐÃ đồng ý.

Cho đến khi chúng ta bắt đầu hành xử như những vấn đề về việc bỏ qua chất lượng để chạy theo deadline như tôi vừa nêu trên, tư duy sẽ không thay đổi, và tệ hơn - hành vi sẽ không thay đổi. Lúc đó deadline sẽ làm át đi chất lượng, đừng để việc đó xảy ra, ít nhất là với team của chính mình. Hãy thay đổi ngay từ bây giờ