Scrum nghe thì không lạ, nhưng để hiểu đúng về Scrum thì cần cả một quá trình tìm hiểu một cách công tâm nhất. Vì sao mình lại dùng từ “Công tâm”? Vì trong quá trình đến với Scrum mình đã gặp rất nhiều người với nhiều quan điểm khác nhau. Trong số đó có cả những người biết về Scrum một cách thoáng qua, hoặc bình luận về Scrum ở mặt nhược điểm. Mình chưa phải là chuyên gia về Scrum, nhưng trong quá trình trải nghiệm Scrum, mình nhận ra mình và nhiều người khác đều có những hiểu lầm cơ bản về Scrum. Vậy những hiểu lầm cơ bản đó là gì? Mình xin phép được chia sẻ như sau:
1. Không được thay đổi Sprint backlog
Theo như mô tả trong Scrum Guide, Sprint Backlog là tập hợp các mục của Product Backlog được chọn và cho vào Sprint, cộng với kế hoạch chuyển giao phần tăng trưởng của sản phẩm và hiện thực hóa mục tiêu của Sprint. Hay nói đơn giản hơn, Sprint backlog là các đầu mục công việc mà nhóm lựa chọn ra từ Product Backlog để hoàn thành mục tiêu đã đề ra trong buổi Planning. Trong một Sprint (1 tuần ~ 4 tuần ), các chức năng hoàn thiện sẽ chuyển giao được. Để nhóm phát triển toàn tâm, tập trung vào công việc và hoàn thành mục tiêu đã đề ra, Scrum Master có trách nhiệm ngăn cản việc thêm công việc vào Sprint hiện tại. Vậy vì sao đây lại là một hiểu nhầm?
Trong thực tế, việc planning luôn là việc lên dự định công việc cho tương lai. Vậy thì dự định vẫn sẽ có những rủi ro nhất định của nó. Sprint backlog chính là kế hoạch để triển khai sprint, là những công việc để hoàn thành mục tiêu đã đề ra đầu Sprint. Trong quá trình thực hiện, chúng ta sẽ thấy rõ hơn những công việc thực tế cần làm, đôi khi sẽ cần điều chỉnh lại các công việc cho phù hợp để hoàn thành mục tiêu.
Ví dụ: Trong buổi Planning, dự kiến để hoàn thành chức năng A thì cần làm 3 đầu mục công việc. Khi làm thực tế, chúng ta nhận thấy, có thể cần làm thêm 1 đầu mục nữa thì chức năng mới hoàn thiện được. Vậy thì Sprint backlog cần được điều chỉnh sao cho phù hợp. Đây cũng chính là lý do cần thiết phải có Daily Scrum để đồng bộ trạng thái công việc và xác định lại công việc cần làm tiếp theo.
Vậy nên Sprint Backlog vẫn có thể thay đổi nhé, chỉ có mục tiêu Sprint mới là thứ không được thay đổi trong suốt Sprint thôi.
2. Burndown chart luôn đi xuống
Thông thường, Burndown chart luôn có xu hướng đi xuống theo thời gian, nên vô hình trung đôi khi khiến chúng ta nhầm tưởng rằng Burndown chart luôn đi xuống.
Burndown chart thể hiện lượng công việc còn lại cần làm và biểu đồ lý tưởng là biểu đồ thể hiện lượng công việc còn lại giảm dần theo thời gian. Nhưng trong thực tế burndown chart không phải lúc nào cũng như kỳ vọng. Sẽ có những lúc bạn thấy burndown đi ngang hoặc thậm chí là đi lên. Vì sao lại vậy? Khi nào thì burndown sẽ đi ngang hoặc đi lên?
Burndown chart
Burndown thể hiện tổng nỗ lực của cả team cần làm để hoàn thành khối lượng công việc còn lại nhằm đảm bảo mục tiêu đã đề ra. Nỗ lực ở đây có thể thể hiện bằng ước tính số giờ cần làm hoặc số point. Lấy luôn ví dụ ở trên, trường hợp dev team nhận thấy mình cần phải làm thêm 1 đầu mục công việc nữa mới có thể hoàn thành mục tiêu, thì khi đó công sức cần bỏ ra để hoàn thành mục tiêu sẽ tăng lên. Và khi đó Burndown chart đi lên.
3. Sprint Retrospective là buổi cải tiến các vấn đề về lỗi con người
Thông thường, trong buổi Retrospective (sau đây xin phép gọi tắt là buổi Retro), chúng ta thường đem cả những lỗi thuộc về yếu tố con người ra thảo luận. Vô hình trung buổi Retro thường mang lại không khí khó chịu, căng thẳng và đôi khi trở thành buổi chỉ trích lẫn nhau. Đôi khi đi vào đường cụt vì giải pháp không hiệu quả, vấn đề vẫn phát sinh ở những Sprint tiếp theo.
Tình huống thường gặp trong buổi Retro:
- Team có người non kinh nghiệm, làm tốn công số review, fix bug, retest, … khiến team chậm tiến độ và thường xuyên phải overtime bù công số.
- Thái độ làm việc của member không tốt: Ít hoặc không support, chưa đọc hiểu đã hỏi,…
Trong buổi Retro, vấn đề “To” đó được đem ra bàn vô hình trung buổi retro sẽ dần trở lên căng thẳng. Nếu đem thái độ, cách thức làm việc hay trình độ bàn trong buổi họp, sẽ làm cho người mắc lỗi kia bị nêu tên ra trước mọi người, gây ảnh hưởng lớn đến tâm trạng, cảm xúc của thành viên trong team. Những vấn đề cá nhân có thể giải quyết bằng cách trao đổi riêng với cá nhân đó, vấn đề trình độ nên dùng phương pháp đào tạo phù hợp để cải thiện thì hơn. Còn buổi retro, mục đích chính là để nhìn nhận lại quy trình, cách thức làm việc trong team đã đúng Scrum hay chưa, có cần cải thiện điều gì không. Tựu chung lại, Scrum là phương pháp thực hành Agile, team cần xem xét lại xem mình đã thực hiện đúng phương pháp hay chưa. Những lỗi đó có gây ảnh hưởng như nào đến năng suất và chất lượng của nhóm hay không và đưa ra giải pháp để hoàn thiện.
4. Tất cả cải tiến Retro đều đem lại hiệu quả làm việc
Khi đưa ra giải pháp cải tiến, team đều hi vọng những giải pháp này có ích cho công việc của team, giúp tăng năng suất làm việc lên hoặc giảm bớt những công việc thừa. Chúng ta tin là nó tốt thì chúng ta mới thống nhất sẽ thực hiện. Nhưng có phải mọi cải tiến đều đem lại hiệu quả hay không thì còn tùy thuộc vào kết quả sau khi áp dụng cải tiến đó.
Để xác minh hiệu quả, chúng ta nên đo lường và đánh giá hiệu quả của cải tiến đó trong quá trình áp dụng. Nên đánh giá lại phương pháp cải tiến đó vào lần retro tiếp theo. Sau khi có kết luận cuối cùng thì sẽ quyết định xem cải tiến đó có thực sự là cải tiến hay không, có đáng để chúng ta tiếp tục làm hay không. Đôi khi, những cái tiến không thích hợp sẽ bị loại bỏ. Vì vậy, không phải cứ là cải tiến thì mang lại hiệu quả cải tiến thực sự.
5. Làm dự án theo Scrum thì sẽ không bị FAIL
Bạn có nghĩ như vậy không? Có không ít người suy nghĩ như vậy để rồi khi thấy dự án vẫn fail thì bảo tất cả chỉ là chém gió, là lý thuyết, chỉ xảy ra trong điều kiện lý tưởng mà thôi. Nói vậy nghĩa là dù có agile, dù có áp dụng Scrum thì dự án vẫn có thể fail. Agile hay Scrum đều không đảm bảo rằng dự án sẽ không fail. Nhưng con số thực tế cho thấy rằng Agile sẽ làm tăng tỉ lệ thành công của dự án.
Bên dưới đây là thống kê vào năm 2012. (Theo https://www.onedesk.com). Qua đó đủ để thấy thực trạng khi áp dụng Scrum vào thực tế, dù áp dụng tốt đến đâu thì khả năng thành công cũng không phải là 100%.
Chú ý: Vì Scrum là phương pháp thực hành Agile, nên dưới đây là biểu đồ so sánh giữa Agile và Waterfall.
Thống kê tỉ lệ dự án thành công, thất bại
6. Nhóm tôi có Scrum nhưng mà…
Đây là câu nói phổ biến nhất mà mình thường được nghe. Khi mang Scrum về áp dụng vào nhóm, có rất nhiều biến số. Vì vậy, thường thì Scrum sẽ được “linh hoạt” thay đổi để “phù hợp” với nhóm. Vậy là có rất nhiều biến thể của Scrum mà chúng ta vẫn lầm tưởng mình đang Scrum thật. Scrum đó thường được gọi với một cái tên khác là ScrumBut để thay cho từ ” team tôi có làm theo Scrum nhưng mà…”. Thực ra, lúc đó không nên gọi nó là Scrum nữa rồi. Nếu có một mô hình làm việc nào đó mang lại hiệu quả cho công việc của bạn, nhưng nó chưa có cái tên nào, thì hãy đặt tên cho nó. Có thể, nó sẽ là trở thành framework mới và hiệu quả đối với những dự án có điểm tương đồng về cả dự án và con người.
Tóm lại
Trên đây chỉ là một vài những hiểu nhầm mà mình đã cóp nhặt được trong quá trình tìm hiểu về Scrum, hy vọng bài này sẽ có ích cho mọi người tránh những hiểu lầm như đã kể trên. Cảm ơn các bạn đã dành thời gian cho bài blog của mình.
COMMENTS