Trong bối cảnh các phương pháp Agile và Scrum, ít khái niệm nào gây ra sự nhầm lẫn và lo lắng nhiều nhưtốc độ. Thường bị coi là bảng điểm hiệu suất bởi ban lãnh đạo hoặc mục tiêu cứng nhắc bởi các đội, chỉ số này thường bỏ qua mục đích ban đầu của nó. Tốc độ là công cụ cho đội, chứ không phải roi quất cho người quản lý. Khi được hiểu đúng, nó mang lại cái nhìn sâu sắc về năng lực và khả năng dự đoán. Khi bị hiểu sai, nó sẽ làm méo mó hành vi và làm suy yếu niềm tin.
Hướng dẫn này khám phá bản chất thực sự của tốc độ, cách nó hoạt động trong khung Scrum, và những ranh giới then chốt giúp duy trì sức khỏe của nó. Chúng ta sẽ đi qua các định nghĩa kỹ thuật, những sai lầm phổ biến dẫn đến hiểu lầm, và các chiến lược sử dụng dữ liệu để cải thiện luồng công việc mà không làm tổn hại đến an toàn tâm lý.
🧩 Tốc độ trong Scrum là gì?
Ở cốt lõi, tốc độ là một thước đo lượng công việc mà một đội Scrum có thể xử lý trong một Sprint duy nhất. Nó không phải là thước đo tốc độ theo nghĩa truyền thống, cũng không phải là tiêu chuẩn phổ quát về năng suất. Thay vào đó, nó là một đơn vị đo tương đối được lấy từ hiệu suất lịch sử của chính đội.
- Nó mang tính hồi tố: Nó được tính dựa trên công việc đã hoàn thành trong các Sprint trước.
- Nó mang tính riêng biệt của đội: Nó phản ánh năng lực, kỹ năng và bối cảnh riêng biệt của một nhóm cụ thể.
- Nó là công cụ hỗ trợ lập kế hoạch: Mục đích chính của nó là giúp đội dự đoán được họ có thể cam kết bao nhiêu công việc trong tương lai.
Tốc độ hoạt động như một yếu tố ổn định. Theo thời gian, nếu một đội duy trì sự nhất quán trong định nghĩa ‘hoàn thành’ và các kỹ thuật ước lượng của họ, con số tốc độ có xu hướng ổn định. Sự ổn định này giúp dự báo sản phẩm tốt hơn. Tuy nhiên, coi con số này là mục tiêu cố định sẽ tạo ra mâu thuẫn.
⚙️ Tốc độ được tính như thế nào
Hiểu rõ cơ chế tính toán là điều cần thiết để hiểu được những hạn chế của chỉ số này. Tốc độ thường được tính dựa trênĐiểm Câu chuyện. Điểm Câu chuyện là một kỹ thuật ước lượng tương đối dùng để đánh giá nỗ lực, độ phức tạp và rủi ro của một câu chuyện người dùng.
Công thức
Phép tính khá đơn giản, nhưng các đầu vào lại đòi hỏi sự kỷ luật:
- Xác định tất cả các Câu chuyện Người dùng đã hoàn thành trong Sprint.
- Đảm bảo rằng Định nghĩa Hoàn thành (DoD) đã được đáp ứng cho từng mục.
- Cộng tổng các Điểm Câu chuyện được gán cho những mục đã hoàn thành.
- Tổng kết quả thu được chính là tốc độ cho Sprint đó.
Quan trọng là, công việc đã bắt đầu nhưng chưa hoàn thành thì không được tính. Công việc được thêm vào muộn nhưng đã hoàn thành thì được tính. Sự phân biệt này rất quan trọng để duy trì độ chính xác.
- Công việc đã hoàn thành: Chỉ những mục hoàn toàn đáp ứng tiêu chí chấp nhận mới góp phần vào điểm số.
- Công việc chưa hoàn thành: Những câu chuyện chưa hoàn thành một nửa sẽ bị bỏ qua trong phép tính.
- Spikes Các đợt nghiên cứu có thời gian giới hạn thường không được tính vào tốc độ, trừ khi chúng tạo ra một phần có thể triển khai được.
- Nợ kỹ thuật:Các nhiệm vụ tái cấu trúc góp phần vào tốc độ nếu chúng đáp ứng tiêu chí hoàn thành, nhưng cần được cân bằng với công việc tính năng.
🚫 Những cách sử dụng sai lầm phổ biến của tốc độ
Nguy hiểm không nằm ở chính thước đo đó, mà ở cách nó được áp dụng bởi các bên liên quan bên ngoài. Khi tốc độ bị tách rời khỏi bối cảnh, nó trở thành nguồn áp lực thay vì công cụ lập kế hoạch. Dưới đây là những cách phổ biến nhất mà thước đo này bị sử dụng sai.
1. So sánh các đội nhóm
Một trong những sai lầm gây hại nhất là so sánh tốc độ của Đội A với Đội B. Sự so sánh này vốn dĩ có vấn đề vì:
- Thang điểm ước lượng khác nhau:Đội A có thể ước lượng một câu chuyện là 5 điểm, trong khi Đội B ước lượng cùng một câu chuyện là 8 điểm dựa trên thang đo riêng của họ.
- Mức độ phức tạp khác nhau:Một đội có thể làm việc trên hệ thống cũ với nợ kỹ thuật cao, trong khi đội khác làm việc trên một dự án hoàn toàn mới.
- Thành phần đội nhóm:Một đội có kiến trúc sư cấp cao sẽ hoạt động khác biệt so với một đội gồm các lập trình viên mới.
Xếp hạng các đội theo tốc độ khuyến khích cạnh tranh nội bộ và làm giảm tinh thần hợp tác. Nó ngụ ý rằng con số cao hơn là tốt hơn, từ đó thúc đẩy việc thổi phồng điểm số.
2. Đặt mục tiêu
Quản lý thường cố gắng đặt mục tiêu tốc độ, ví dụ như “Chúng tôi cần các bạn đạt 40 điểm mỗi sprint.” Điều này biến một thước đo mô tả thành mục tiêu bắt buộc. Khi tốc độ trở thành mục tiêu, những hành vi sau đây sẽ xuất hiện:
- Thổi phồng ước lượng:Các thành viên đội có thể thổi phồng điểm câu chuyện để đảm bảo đạt được mục tiêu.
- Cắt giảm phạm vi:Các đội có thể chia nhỏ tính năng để tăng số lượng một cách giả tạo.
- Hy sinh chất lượng:Trọng tâm chuyển từ việc mang lại giá trị sang đạt con số, có thể bỏ qua kiểm thử hoặc tài liệu hóa.
3. Dự đoán ngày cho các bên liên quan
Sử dụng tốc độ để hứa một ngày phát hành cụ thể cho khách hàng dựa trên hiệu suất của một sprint duy nhất là rủi ro. Tốc độ thay đổi theo thời gian. Một đội có thể có sprint chậm do nghỉ lễ, nghỉ ốm hoặc các rào cản kỹ thuật bất ngờ. Dùng một điểm dữ liệu để cam kết ngày phát hành sẽ tạo ra kỳ vọng không thực tế.
4. Đo lường hiệu suất cá nhân
Tốc độ là thước đo của đội nhóm. Chia nhỏ nó để đo lường hiệu suất cá nhân là vi phạm nguyên tắc Scrum. Agile dựa vào sự hợp tác đa chức năng. Nếu một lập trình viên hoàn thành 5 điểm và người khác hoàn thành 8 điểm, việc so sánh chúng sẽ bỏ qua mức độ phức tạp của công việc và các mối phụ thuộc giữa chúng.
✅ Ứng dụng đúng cách của tốc độ
Khi được sử dụng đúng cách, tốc độ hỗ trợ quản lý tự chủ của đội nhóm. Nó là tấm gương, chứ không phải cây búa. Dưới đây là cách tận dụng nó một cách hiệu quả.
1. Lập kế hoạch Sprint
Cách sử dụng phù hợp nhất của tốc độ là trong lập kế hoạch Sprint. Bằng cách xem xét tốc độ trung bình của 3 đến 5 sprint gần nhất, đội có thể xác định được năng lực thực tế cho sprint sắp tới.
- Tính toán trung bình:Cộng tổng điểm của 3-5 Sprint gần nhất và chia cho số lượng Sprint.
- Cam kết:Đội sẽ kéo công việc vào Sprint cho đến khi tổng số điểm ước tính phù hợp với trung bình này.
- Đệm:Là khôn ngoan khi lập kế hoạch ở mức thấp hơn một chút so với trung bình để tính đến các gián đoạn hoặc công việc bất ngờ.
2. Dự báo phát hành
Tốc độ giúp trả lời câu hỏi: “Sản phẩm sẽ sẵn sàng khi nào?” Bằng cách chia tổng số điểm còn lại trong danh sách công việc sản phẩm cho tốc độ trung bình, đội có thể ước tính số Sprint cần thiết để hoàn thành công việc.
- Khoảng thời gian, không phải ngày cụ thể:Trình bày dự báo dưới dạng khoảng thời gian (ví dụ: “Giữa Sprint 10 và 12”) thay vì một ngày cụ thể trên lịch.
- Cập nhật liên tục:Cập nhật dự báo thường xuyên khi có thông tin mới xuất hiện hoặc khi danh sách công việc thay đổi.
- Minh bạch:Chia sẻ dự báo một cách cởi mở với các bên liên quan để họ hiểu mối quan hệ giữa phạm vi và thời gian.
3. Nhận diện xu hướng
Theo dõi tốc độ theo thời gian có thể tiết lộ các chỉ số sức khỏe trong đội hoặc quy trình.
- Giảm đều đặn:Sự suy giảm đều đặn có thể cho thấy kiệt sức, nợ kỹ thuật gia tăng, hoặc thay đổi trong thành phần đội.
- Tăng đột biến đều đặn:Sự gia tăng đột ngột có thể cho thấy các ước tính trước đó quá bảo thủ hoặc đội đã tìm ra quy trình hiệu quả hơn.
- Biến động:Sự biến động cao cho thấy sự bất ổn trong quy trình hoặc trong Định nghĩa Hoàn thành.
📉 Tốc độ so với Năng lực
Rất quan trọng khi phân biệt tốc độ và năng lực. Nhầm lẫn hai khái niệm này dẫn đến cam kết quá mức.
- Năng lực:Chỉ thời gian sẵn có (theo giờ) mà đội có để làm việc. Điều này bao gồm nghỉ phép, họp hành và các nhiệm vụ hỗ trợ.
- Tốc độ:Chỉ lượng công việc (điểm) đã hoàn thành. Điều này phản ánh tốc độ và hiệu quả của đội.
Một đội có thể có năng lực cao (nhiều giờ làm việc sẵn có) nhưng tốc độ thấp (gặp khó khăn với độ phức tạp). Ngược lại, một đội có thể có năng lực thấp (nhiều cuộc họp) nhưng tốc độ cao (hiệu quả cao). Lập kế hoạch đòi hỏi sự cân bằng cả hai yếu tố.
| Chỉ số | Đơn vị đo lường | Mục đích chính | Ai nên sử dụng nó |
|---|---|---|---|
| Tốc độ | Điểm truyện | Dự báo và lập kế hoạch | Đội Scrum |
| Năng lực | Giờ | Khả năng lập lịch | Đội Scrum và Scrum Master |
| Sụt giảm | Giờ/Điểm | Theo dõi tiến độ | Các bên liên quan và đội nhóm |
🧠 Tâm lý học về chỉ số
Các chỉ số ảnh hưởng đến hành vi. Đây là một nguyên tắc cơ bản của tâm lý học tổ chức. Nếu bạn đo lường X, mọi người sẽ tối ưu hóa cho X. Khi tốc độ là thước đo chính của thành công, đội nhóm sẽ tối ưu hóa cho tốc độ, chứ không phải giá trị.
An toàn tâm lý
Để tốc độ chính xác, đội nhóm phải cảm thấy an toàn khi thừa nhận khi công việc bị chặn hoặc khi ước lượng sai. Nếu một đội nhóm sợ rằng tốc độ thấp sẽ dẫn đến hình phạt, họ sẽ:
- Đánh giá thấp rủi ro.
- Giấu các trở ngại.
- Tránh nhận các nhiệm vụ phức tạp.
Điều này dẫn đến ảo giác về tiến bộ. Các con số tốc độ cao trong một môi trường sợ hãi thường là dấu hiệu của sự bất ổn, chứ không phải hiệu quả.
Cải tiến liên tục
Tốc độ nên được thảo luận trong buổi tổng kết, nhưng không phải như một KPI. Thay vào đó, hãy thảo luận về quy trìnhđã dẫn đến tốc độ.
- Tại sao sprint này lại chậm hơn bình thường?
- Chúng ta có quá nhiều gián đoạn không?
- Liệu Định nghĩa Hoàn thành có quá khắt khe hay quá lỏng lẻo không?
Bằng cách tập trung vào quy trình, đội cải thiện hệ thống nền tảng, điều này tự nhiên giúp tốc độ ổn định theo thời gian.
🔄 Xử lý các biến động và bất thường
Không phải tất cả các Sprint nào cũng giống nhau. Các biến động về tốc độ là điều bình thường và thường được mong đợi. Hiểu rõ lý do vì sao những biến động này xảy ra là chìa khóa để diễn giải dữ liệu một cách chính xác.
1. Thay đổi đội nhóm
Nếu một nhà phát triển rời đi hoặc một thành viên mới gia nhập, tốc độ sẽ có khả năng thay đổi. Thành viên mới có đường cong học tập. Họ có thể mất nhiều thời gian hơn để hoàn thành nhiệm vụ, hoặc có thể đóng góp theo cách không lường trước. Không nên kỳ vọng tốc độ sẽ nhanh chóng đạt mức tương đương với các con số trước đó.
2. Mở rộng phạm vi công việc
Nếu các bên liên quan thêm công việc trong giữa Sprint, tốc độ có thể giảm do đội nhóm có ít thời gian hơn cho các nhiệm vụ đã cam kết. Ngược lại, nếu đội nhóm thành công trong việc hấp thụ thay đổi, tốc độ có thể duy trì ổn định, nhưng điều này tiềm ẩn nguy cơ kiệt sức. Tốt hơn hết là từ chối các thay đổi phạm vi hoặc chuyển chúng vào danh sách công việc chờ xử lý.
3. Nợ kỹ thuật
Khi nợ kỹ thuật tích lũy, tốc độ thường giảm do yêu cầu nhiều nỗ lực hơn để thực hiện thay đổi. Đây là dấu hiệu để dành các Sprint cho việc tái cấu trúc mã nguồn. Bỏ qua điều này sẽ dẫn đến sự suy giảm dần dần về hiệu suất.
📊 Tóm tắt: Nên và Không nên
Để đảm bảo tốc độ vẫn là một công cụ hữu ích, hãy tuân theo các hướng dẫn sau.
| Nên ✅ | Không nên ❌ |
|---|---|
| Chỉ sử dụng nó cho lập kế hoạch nội bộ. | Sử dụng nó để so sánh các đội nhóm. |
| Tính toán dựa trên công việc đã hoàn thành. | Đếm công việc được hoàn thành một phần. |
| Thảo luận về xu hướng trong các buổi tổng kết. | Đặt nó làm mục tiêu hiệu suất. |
| Tập trung vào ước lượng tương đối. | Tập trung vào số giờ hoặc sản lượng cá nhân. |
| Chấp nhận sự biến động như một điều bình thường. | Trừng phạt sự giảm tốc độ. |
| Cập nhật danh sách công việc chờ xử lý thường xuyên. | Khóa phạm vi trong thời gian dài. |
🚀 Những cân nhắc cuối cùng cho sự phát triển bền vững
Tốc độ là hệ quả của một hệ thống khỏe mạnh. Nếu hệ thống khỏe mạnh, tốc độ sẽ ổn định. Nếu hệ thống bị hỏng, tốc độ sẽ biến động mạnh hoặc suy giảm. Mục tiêu không phải là tối đa hóa tốc độ; mục tiêu là tối đa hóa việc cung cấp giá trị.
Khi ban lãnh đạo hiểu rằng tốc độ là một giới hạn trong lập kế hoạch chứ không phải là động cơ năng suất, thì bản chất của tình hình thay đổi. Các đội cảm thấy được trao quyền để tự xác định nhịp độ của mình dựa trên bằng chứng. Các bên liên quan học cách quản lý kỳ vọng dựa trên phạm vi thay vì những lời hứa. Trọng tâm quay trở lại việc cung cấp phần mềm chất lượng nhằm giải quyết các vấn đề của người dùng.
Hãy nhớ rằng các chỉ số là công cụ để kiểm tra và thích nghi. Chúng không phải là mục đích cuối cùng. Hãy giữ đội nhóm ở trung tâm của cuộc trò chuyện. Để dữ liệu hỗ trợ ra quyết định, nhưng để phán đoán con người định hướng chiến lược.
🔍 Câu hỏi thường gặp
Tốc độ có thể tăng vô hạn không?
Không. Có những giới hạn về thể chất và nhận thức đối với lượng công việc mà một đội có thể tiếp nhận. Khi độ phức tạp tăng lên, tốc độ thường đạt đến mức bão hòa hoặc giảm xuống. Sự tăng trưởng liên tục của tốc độ thường cho thấy các tiêu chuẩn ước lượng đang suy giảm, chứ không phải năng suất đang tăng lên.
Thế nếu chúng ta không dùng Điểm Câu chuyện?
Tốc độ có thể được tính toán bằng các đơn vị khác nhau, chẳng hạn như giờ hoặc ngày lý tưởng, mặc dù Điểm Câu chuyện được ưa chuộng hơn vì chúng tách biệt khỏi thời gian. Dù sử dụng đơn vị nào, nguyên tắc vẫn như nhau: đo lường công việc hoàn thành dựa trên hiệu suất trong quá khứ.
Tốc độ có tính đến các lỗi không?
Chỉ khi việc sửa lỗi đáp ứng Tiêu chuẩn Hoàn thành. Nếu việc sửa lỗi là một nhiệm vụ mới được thêm vào danh sách công việc, điểm số của nó sẽ được tính vào tốc độ sau khi hoàn thành. Nếu đó là lỗi trong công việc đã được giao, thường được xử lý như một sự cố riêng biệt.
Chúng ta nên trung bình bao nhiêu Sprint?
Ít nhất ba Sprint sẽ cung cấp một cơ sở tham chiếu. Năm đến mười Sprint sẽ mang lại đường xu hướng ổn định hơn. Hãy sử dụng dữ liệu gần đây nhất vì nó phản ánh trạng thái và bối cảnh hiện tại của đội.
Bằng cách tôn trọng những sắc thái của tốc độ, các đội có thể tránh được những cái bẫy của quản lý dựa trên chỉ số. Chỉ số phục vụ đội, chứ không phải ngược lại. Sự cân bằng này tạo ra một môi trường mà tính dự đoán và chất lượng có thể cùng phát triển.
