Việc ước lượng trong phát triển phần mềm thường là nguồn gây mâu thuẫn giữa các chủ sản phẩm và các đội kỹ thuật. Khi một câu chuyện không rõ ràng, các nhà phát triển không thể đưa ra ước lượng chính xác về nỗ lực. Điều này dẫn đến việc lập kế hoạch sprint không đáng tin cậy, các mốc thời gian bị bỏ lỡ và sự thất vọng trong đội nhóm. Nguyên nhân gốc rễ hiếm khi là thiếu kỹ năng kỹ thuật; thường là do thiếu sự rõ ràng trong yêu cầu.
Để lấp đầy khoảng cách này, các câu chuyện người dùng phải được viết một cách chính xác. Chúng nên cung cấp đủ bối cảnh để một nhà phát triển hiểu được cái gì, tại sao, và các giới hạn của công việc. Hướng dẫn này khám phá cách xây dựng các câu chuyện người dùng giúp việc ước lượng chính xác trong khung Scrum, mà không cần dựa vào công cụ bên ngoài hay những lời quảng cáo hoa mỹ.
🤔 Tại sao việc ước lượng lại thất bại
Các nhà phát triển không ước lượng thời gian; họ ước lượng nỗ lực, độ phức tạp và rủi ro. Khi một câu chuyện người dùng mơ hồ, các biến số chưa biết sẽ làm tăng rủi ro, từ đó làm tăng ước lượng. Dưới đây là những lý do phổ biến khiến các câu chuyện khó ước lượng:
- Thiếu tiêu chí chấp nhận:Không có ranh giới rõ ràng, các nhà phát triển sẽ giả định tình huống xấu nhất.
- Các phụ thuộc kỹ thuật:Những câu chuyện phụ thuộc vào công việc chưa hoàn thành từ các đội khác sẽ tạo ra sự không chắc chắn.
- Động từ mơ hồ:Những thuật ngữ như “tối ưu hóa”, “nâng cao” hay “cải thiện” thiếu các kết quả có thể đo lường được.
- Kiến thức được giả định:Dựa vào kiến thức truyền miệng thay vì bối cảnh được ghi chép rõ ràng.
- Quá nhiều câu chuyện:Những câu chuyện lớn, đơn thể, bao quát quá nhiều nội dung cùng lúc.
Khi một nhà phát triển hỏi: “Nhưng nó hoạt động như thế nào chính xác?”, thì câu chuyện chưa sẵn sàng để ước lượng. Mục tiêu là giảm nhu cầu đặt câu hỏi làm rõ trong giai đoạn lập kế hoạch sprint.
📐 Mô hình INVEST cho các câu chuyện có thể ước lượng
Mô hình INVEST là một cách ghi nhớ được dùng để định nghĩa các câu chuyện người dùng tốt. Dù thường được trích dẫn, nhưng nhiều đội lại bỏ qua các khía cạnh Nhỏ và Có thể kiểm thửlà những yếu tố then chốt cho việc ước lượng.
1. Độc lập
Các câu chuyện nên độc lập về lý tưởng. Nếu một câu chuyện phụ thuộc vào một câu chuyện khác phải hoàn thành trước, đội không thể ước lượng nó một cách độc lập. Các phụ thuộc sẽ tạo ra sự tắc nghẽn. Nếu một câu chuyện thực sự phụ thuộc, nó nên được chia nhỏ cho đến khi phụ thuộc được giải quyết hoặc câu chuyện đủ nhỏ để có thể thử nghiệm (spike).
2. Có thể thương lượng
Các câu chuyện không phải là hợp đồng; chúng là chỗ trống cho một cuộc trò chuyện. Tuy nhiên, cuộc trò chuyện phải diễn ra trước ước tính. Nếu một câu chuyện được viết dưới dạng tài liệu cụ thể cố định mà không có chỗ cho thảo luận kỹ thuật, điều này sẽ giới hạn khả năng của nhà phát triển đề xuất một giải pháp tốt hơn, có thể ảnh hưởng đến ước tính.
3. Có giá trị
Mỗi câu chuyện phải mang lại giá trị cho người dùng cuối. Nếu một câu chuyện chỉ là cơ sở hạ tầng kỹ thuật thuần túy mà không có giá trị hiển thị với người dùng, thì đó là một nhiệm vụ kỹ thuật, chứ không phải là một câu chuyện người dùng. Các nhiệm vụ kỹ thuật đòi hỏi phương pháp ước tính khác nhau và cần được xử lý cẩn trọng để tránh làm phình to vòng lặp sprint.
4. Có thể ước tính
Đây là yêu cầu cốt lõi cho hướng dẫn này. Một câu chuyện có thể ước tính nếu đội ngũ có đủ thông tin để xác định nỗ lực cần thiết. Điều này có nghĩa là:
- Luồng người dùng rõ ràng.
- Yêu cầu dữ liệu đã được xác định.
- Các trường hợp biên đã được xem xét.
- Các yêu cầu về hiệu suất đã được nêu rõ (ví dụ: thời gian tải).
5. Nhỏ
Độ chính xác của việc ước tính giảm khi kích thước tăng lên. Một câu chuyện mất hai tuần để hoàn thành là quá lớn. Nó nên được chia thành các câu chuyện mất từ một đến ba ngày. Các câu chuyện nhỏ giúp giảm rủi ro và cải thiện độ chi tiết của ước tính.
6. Có thể kiểm thử
Nếu bạn không thể viết một bài kiểm thử cho câu chuyện, bạn sẽ không thể xác định các tiêu chí chấp nhận. Nếu bạn không thể xác định các tiêu chí chấp nhận, nhà phát triển sẽ không biết khi nào câu chuyện được hoàn thành. Điều này ảnh hưởng trực tiếp đến việc ước tính vì ‘hoàn thành’ chính là đích đến.
🛠 Cấu trúc của một câu chuyện người dùng chất lượng cao
Một câu chuyện người dùng không chỉ đơn thuần là một tiêu đề. Đó là một gói thông tin. Để đảm bảo các nhà phát triển có thể ước tính hiệu quả, mỗi câu chuyện nên chứa các thành phần sau.
1. Tiêu đề
Tiêu đề nên mô tả rõ ràng nhưng ngắn gọn. Nó nên tóm tắt chức năng cốt lõi.
- Kém:Sửa đăng nhập
- Tốt:Cho phép người dùng đặt lại mật khẩu thông qua liên kết email
2. Câu tuyên bố người dùng
Định dạng chuẩn là: “Là một [vai trò], tôi muốn [tính năng], để [lợi ích].” Điều này đảm bảo đội ngũ hiểu được bối cảnh.
3. Bối cảnh và thông tin nền
Các nhà phát triển cần biết bối cảnh kinh doanh. Tại sao tính năng này lại được xây dựng ngay bây giờ? Có yêu cầu quy định nào không? Đây có phải là sửa một lỗi nghiêm trọng không? Bối cảnh giúp các nhà phát triển ưu tiên các quyết định kỹ thuật.
4. Tiêu chí chấp nhận
Đây là phần quan trọng nhất đối với việc ước tính. Các tiêu chí chấp nhận xác định ranh giới công việc. Chúng nên được viết theo cách cho phép kiểm thử tự động.
- Sử dụng Câu điều kiện – Khi – Thì:Cấu trúc này giảm thiểu sự mơ hồ.
- Xác định các trường hợp biên:Điều gì sẽ xảy ra nếu internet bị ngắt? Điều gì sẽ xảy ra nếu đầu vào trống?
- Xác định dữ liệu:Chúng ta đang trích xuất từ cơ sở dữ liệu hiện có chứ? Chúng ta đang tạo các bản ghi mới chứ?
📋 So sánh: Câu chuyện mơ hồ vs. Câu chuyện rõ ràng
Hiểu được sự khác biệt giữa một câu chuyện gây ra sai lệch trong ước tính và một câu chuyện giúp làm rõ là điều then chốt. Bảng dưới đây nêu bật sự khác biệt này.
| Tính năng | Câu chuyện mơ hồ (khó ước tính) | Câu chuyện rõ ràng (dễ ước tính) |
|---|---|---|
| Mục tiêu | Nâng cao hiệu suất bảng điều khiển. | Giảm thời gian tải bảng điều khiển xuống dưới 2 giây cho 1000 bản ghi. |
| Phạm vi | Tối ưu hóa phía máy chủ. | Chỉ mục cột ‘user_id’ trong bảng tìm kiếm và lưu trữ tạm kết quả hàng đầu 50 mục. |
| Tiêu chí chấp nhận | Phải nhanh hơn. | 1. Thời gian tải < 2 giây. 2. Không có lỗi với 1000 bản ghi. 3. Chế độ xem di động hoạt động. |
| Phụ thuộc | Không có gì được đề cập. | Yêu cầu truy cập vào API Phân tích, hiện đang ở giai đoạn thử nghiệm. |
🧩 Xử lý các phụ thuộc và rủi ro
Các phụ thuộc là kẻ thù của việc ước tính. Nếu một câu chuyện phụ thuộc vào API của đội khác, thì ước tính là chỉ dự đoán. Để giảm thiểu điều này:
- Phát hiện sớm:Thảo luận về các phụ thuộc trong quá trình tinh chỉnh danh sách công việc, chứ không phải trong giai đoạn lập kế hoạch.
- Tạo các câu chuyện nghiên cứu (spike):Nếu phụ thuộc chưa rõ, hãy tạo một câu chuyện để điều tra nó. Một spike là một nhiệm vụ nghiên cứu có thời gian giới hạn. Nó không tạo ra mã nguồn, nhưng tạo ra kiến thức giúp giảm rủi ro.
- Dữ liệu giả:Nếu dịch vụ bên ngoài không khả dụng, hãy thống nhất cấu trúc phản hồi giả. Điều này cho phép phát triển tiếp tục mà không bị đình trệ.
- Phụ thuộc bên ngoài: Nếu một câu chuyện phụ thuộc vào một dịch vụ bên thứ ba, hãy ghi chú các tác động về chi phí và độ trễ trong phần mô tả.
🗣 Vai trò của cuộc trò chuyện
Viết câu chuyện chỉ là một nửa công việc. Cuộc trò chuyện là nửa còn lại. Câu chuyện được viết ra chỉ là lời nhắc về cuộc trò chuyện, chứ không phải chính cuộc trò chuyện đó.
Tinh chỉnh trước khi lập kế hoạch
Trước khi lập kế hoạch sprint, đội cần xem xét lại danh sách công việc chờ xử lý. Đây là lúc để đặt câu hỏi. Nếu một nhà phát triển nhận thấy khoảng trống trong câu chuyện, họ nên báo ngay lập tức. Một câu chuyện được đánh dấu trong quá trình tinh chỉnh là một câu chuyện đã sẵn sàng để ước lượng.
Câu hỏi làm rõ
Trong quá trình tinh chỉnh, các câu hỏi cụ thể cần được trả lời. Ví dụ:
- Tính năng này có cần được truy cập được không?
- Có yêu cầu các giao thức bảo mật cụ thể nào không?
- Số lượng người dùng tối đa dự kiến là bao nhiêu?
- Chúng ta có cần hỗ trợ các trình duyệt cũ không?
Nếu những câu trả lời này được ghi chú trong câu chuyện, thì ước lượng sẽ trở nên đáng tin cậy hơn.
📊 Hiểu về các kỹ thuật ước lượng
Khi câu chuyện đã rõ ràng, đội cần một phương pháp để ước lượng. Điều quan trọng không phải là phương pháp đó mà là sự đồng thuận mà nó tạo ra.
Điểm câu chuyện
Điểm câu chuyện đo lường nỗ lực tương đối, độ phức tạp và rủi ro. Chúng không phải là giờ. Việc sử dụng điểm câu chuyện giúp các đội tập trung vào quy mô công việc thay vì tốc độ của từng cá nhân.
- Độ phức tạp:Logic này khó đến mức nào?
- Rủi ro:Khả năng xảy ra lỗi là bao nhiêu?
- Nỗ lực:Có bao nhiêu công việc tham gia?
Poker lập kế hoạch
Đây là một kỹ thuật dựa trên sự đồng thuận. Mỗi nhà phát triển giơ lên một thẻ có con số. Nếu các con số khác nhau, những người ước lượng cao nhất và thấp nhất sẽ giải thích lý do của mình. Điều này phơi bày những giả định ẩn giấu. Ví dụ, một nhà phát triển có thể đã quên yêu cầu tích hợp, trong khi người khác lại cho rằng nó đã được xây dựng sẵn.
🚫 Những sai lầm phổ biến cần tránh
Ngay cả với những ý định tốt, các đội thường rơi vào những cái bẫy làm hỏng độ chính xác của việc ước lượng.
1. Chỉ đường đi thuận lợi
Viết các câu chuyện chỉ mô tả tình huống lý tưởng là rất nguy hiểm. Các nhà phát triển sẽ ước lượng theo đường đi thuận lợi, nhưng công việc thực tế bao gồm xử lý lỗi. Luôn luôn bao gồm các trạng thái lỗi trong tiêu chí chấp nhận.
2. Bỏ qua các yêu cầu phi chức năng
Hiệu suất, bảo mật và khả năng mở rộng thường bị bỏ qua. Một câu chuyện nói “Tạo người dùng” có thể chỉ mất 1 điểm. Nhưng một câu chuyện nói “Tạo người dùng hỗ trợ 10.000 đăng nhập đồng thời” lại mất 10 điểm. Hãy nêu rõ các yêu cầu phi chức năng.
3. Gây quá nhiều chi tiết trong mô tả
Đừng viết một tài liệu kỹ thuật trong câu chuyện người dùng. Nhà phát triển cần biết gìcần xây dựng, chứ không phải cáchđể xây dựng nó. Nếu bạn xác định lược đồ cơ sở dữ liệu trong câu chuyện, bạn sẽ giới hạn khả năng lựa chọn giải pháp tốt nhất của nhà phát triển.
4. Bỏ qua Định nghĩa Hoàn thành
Định nghĩa Hoàn thành (DoD) áp dụng cho mọi câu chuyện. Nó bao gồm kiểm thử, kiểm tra mã nguồn và tài liệu. Nếu DoD không rõ ràng, ước tính sẽ sai lệch. Đảm bảo cả đội đồng thuận về nghĩa của “hoàn thành” trước khi ước tính.
🔄 Quy trình làm việc của quá trình tinh chỉnh
Để duy trì luồng câu chuyện có thể ước tính ổn định, hãy tuân theo quy trình này.
- Bản nháp ban đầu:Người sở hữu sản phẩm viết câu chuyện với các chi tiết cơ bản.
- Xem xét kỹ thuật:Các nhà phát triển xem xét về tính khả thi và độ phức tạp ẩn.
- Mở rộng tiêu chí chấp nhận:Thêm các trường hợp biên và ràng buộc.
- Kiểm tra phụ thuộc:Xác minh không có rào cản nào tồn tại.
- Ước tính cuối cùng:Đội phân bổ điểm câu chuyện trong quá trình tinh chỉnh hoặc lập kế hoạch.
- Xác thực:Đảm bảo câu chuyện đáp ứng các tiêu chí INVEST.
📈 Đo lường độ chính xác của ước tính
Theo thời gian, các đội nên theo dõi độ chính xác ước tính của mình. Điều này không nhằm trừng phạt cá nhân, mà để cải thiện quy trình.
- Theo dõi tốc độ:Theo dõi tốc độ của đội trong nhiều sprint. Nếu tốc độ dao động mạnh, các câu chuyện có khả năng không nhất quán.
- Tỷ lệ hoàn thành:Đội có hoàn thành tất cả các câu chuyện đã ước tính không? Nếu không, họ có bị chặn hay ước tính thấp không?
- Tần suất ước tính lại:Nếu các câu chuyện được ước tính lại thường xuyên trong sprint, thì ước tính ban đầu là sai lệch.
🛡 Bảo mật và tuân thủ
Đối với các ngành bị quản lý, bảo mật và tuân thủ là một phần của ước tính. Một câu chuyện xử lý dữ liệu người dùng đòi hỏi nỗ lực khác biệt so với một câu chuyện hiển thị thông tin công khai. Hãy bao gồm các kiểm tra tuân thủ trong tiêu chí chấp nhận.
- Bảo mật dữ liệu:Câu chuyện này có liên quan đến thông tin nhận dạng cá nhân (PII) không?
- Dòng nhật ký kiểm toán:Hệ thống có cần ghi lại ai đã thực hiện thay đổi không?
- Mã hóa:Dữ liệu có được mã hóa khi lưu trữ hay đang truyền tải không?
Nếu các yêu cầu này không được nêu rõ, nhà phát triển có thể xây dựng một giải pháp yêu cầu tái cấu trúc lớn sau này, làm phí phạm ước tính ban đầu.
🧪 Giá trị của các Spikes
Đôi khi, một câu chuyện quá rủi ro để ước tính. Trong những trường hợp này, hãy sử dụng Spike. Spike là một cuộc điều tra có giới hạn thời gian. Nó không phải là một tính năng có thể giao, mà là một nhiệm vụ học tập.
Ví dụ:
- Câu chuyện: Khảo sát tính khả thi khi tích hợp với cổng thanh toán cũ.
- Mục tiêu: Xác định xem cổng có hỗ trợ phiên bản API yêu cầu của chúng ta hay không.
- Kết quả: Một tài liệu chứa kết quả khảo sát và đề xuất.
Sau khi spike hoàn thành, câu chuyện tính năng thực tế có thể được ước tính dựa trên kết quả khảo sát. Điều này làm giảm đáng kể rủi ro.
🤝 Hợp tác với QA
Chất lượng đảm bảo (QA) nên tham gia vào quá trình tinh chỉnh. Các nhà phát triển có thể bỏ sót các trường hợp biên mà người kiểm thử phát hiện. QA có thể giúp viết tiêu chí chấp nhận từ góc nhìn kiểm thử. Điều này đảm bảo câu chuyện thực sự có thể kiểm thử, là một thành phần then chốt trong quá trình ước tính.
📉 Quản lý hiện tượng mở rộng phạm vi
Hiện tượng mở rộng phạm vi xảy ra khi yêu cầu thay đổi sau khi đã ước tính. Để ngăn chặn điều này:
- Cứng hóa tiêu chí:Sau khi ước tính, tiêu chí chấp nhận không được thay đổi mà không có việc ước tính lại.
- Yêu cầu thay đổi:Nếu cần thay đổi, phải ghi lại và thêm vào danh sách công việc, không được ép buộc vào sprint hiện tại.
- Minh bạch:Nếu thay đổi là không thể tránh khỏi, hãy thông báo ngay lập tức về tác động đến mục tiêu sprint.
🧠 Chia sẻ kiến thức
Ước lượng là một môn thể thao tập thể. Các nhà phát triển cấp thấp có thể ước lượng khác với cấp cao. Để đồng bộ đội ngũ:
- Các buổi hiệu chuẩn: Thường xuyên xem xét lại các câu chuyện trước đây để hiệu chuẩn xem “5” trông như thế nào so với “13”.
- Làm việc theo cặp: Sử dụng làm việc theo cặp cho các câu chuyện phức tạp để chia sẻ kiến thức và giảm độ lệch trong ước lượng.
- Tài liệu: Duy trì một thư viện các câu chuyện trước đây để làm điểm tham chiếu cho các ước lượng tương lai.
🌟 Những suy nghĩ cuối cùng về sự rõ ràng
Viết các câu chuyện người dùng mà các nhà phát triển có thể ước lượng dễ dàng là một bài tập về sự thấu cảm. Điều này đòi hỏi người sở hữu sản phẩm phải đặt mình vào vị trí của kỹ sư và dự đoán các câu hỏi của họ. Điều này cũng đòi hỏi kỹ sư phải lên tiếng khi thông tin thiếu hụt. Khi cả hai bên hợp tác để loại bỏ sự mơ hồ, việc ước lượng trở thành một công cụ đáng tin cậy cho việc lập kế hoạch.
Kết quả không chỉ là những con số chính xác. Đó là sự tin tưởng. Khi đội ngũ cam kết thực hiện một bộ câu chuyện dựa trên các tiêu chí rõ ràng, họ có thể giao hàng với sự tự tin. Trọng tâm chuyển từ việc đoán mò sang việc xây dựng.
🔑 Những điểm chính cần lưu ý
- Sự rõ ràng là vua:Một câu chuyện rõ ràng là một câu chuyện có thể ước lượng được.
- Tiêu chí chấp nhận: Xác định rõ ràng các ranh giới và các trường hợp biên.
- Các phụ thuộc: Xác định và giảm thiểu rủi ro trước khi lập kế hoạch.
- Cuộc trò chuyện: Sử dụng làm rõ để thảo luận chi tiết trước khi ước lượng.
- Câu chuyện nhỏ: Chia nhỏ công việc lớn để cải thiện độ chính xác.
- Cải tiến liên tục: Theo dõi tốc độ và điều chỉnh quy trình theo thời gian.
Bằng cách tuân thủ những nguyên tắc này, các đội có thể biến việc lập kế hoạch sprint từ một trò chơi đoán mò thành một quy trình có cấu trúc và dự đoán được. Nỗ lực bỏ ra để viết các câu chuyện tốt sẽ mang lại lợi ích trong mỗi sprint tiếp theo.