Bước vào thế giới của Scrum và phát triển Agile thường mang đến sự kết hợp giữa háo hức và bất ổn. Một trong những nguyên nhân phổ biến gây lo lắng cho các lập trình viên mới là quá trình ước lượng. Làm thế nào để dự đoán thời gian một nhiệm vụ sẽ mất? Làm thế nào để truyền đạt độ phức tạp cho đội nhóm? Việc ước lượng chính xác không phải là đoán mò; đó là việc hiểu rõ phạm vi, rủi ro và nỗ lực.
Hướng dẫn này phân tích các kỹ thuật ước lượng thiết yếu được sử dụng trong môi trường Scrum. Chúng ta sẽ khám phá kích thước tương đối, lập kế hoạch hợp tác và cách xây dựng sự tự tin trong dự đoán mà không cần phụ thuộc vào công cụ phần mềm cụ thể. Dù bạn mới gia nhập đội nhóm hay đang tìm cách hoàn thiện kỹ năng, những phương pháp này sẽ giúp bạn đóng góp hiệu quả vào lập kế hoạch sprint.
Tại sao việc ước lượng lại quan trọng trong Scrum 🤔
Việc ước lượng thường bị nhầm lẫn với lời hứa về ngày giao hàng. Trên thực tế, đó là một công cụ để lập kế hoạch và quản lý rủi ro. Đối với một lập trình viên mới, việc hiểu được ‘tại sao’ chúng ta ước lượng sẽ giúp giảm áp lực phải chính xác tuyệt đối mỗi lần. Dưới đây là những lý do cốt lõi tại sao chúng ta tiến hành ước lượng:
- Ưu tiên:Người sở hữu sản phẩm cần biết nỗ lực cần thiết để quyết định những gì sẽ được đưa vào sprint tiếp theo.
- Lập kế hoạch năng lực:Đội nhóm cần hiểu được khối lượng công việc nào có thể thực sự phù hợp vào một khung thời gian nhất định.
- Phát hiện rủi ro:Những con số ước lượng lớn thường là dấu hiệu của rủi ro cao hoặc yêu cầu chưa rõ ràng, cần được điều tra thêm.
- Tốc độ đội nhóm:Theo thời gian, các ước lượng giúp đội nhóm đo lường hiệu suất thực tế và cải thiện độ dự đoán được.
Khi bạn tham gia vào quá trình ước lượng, bạn không chỉ đang gán một con số. Bạn đang tham gia vào cuộc trao đổi với đội nhóm để làm rõ yêu cầu. Chính cuộc trao đổi này mới là nơi tạo nên giá trị thực sự.
Hiểu rõ sự khác biệt giữa ước lượng tương đối và tuyệt đối ⚖️
Có hai phương pháp chính để xác định kích thước công việc trong Agile. Là một lập trình viên mới, điều quan trọng là phải hiểu rõ sự khác biệt để tránh những sai lầm phổ biến.
Ước lượng tuyệt đối
Ước lượng tuyệt đối sử dụng các đơn vị thời gian cố định, chẳng hạn như giờ hoặc ngày. Mặc dù điều này có vẻ trực quan, nhưng thường dẫn đến dự đoán không chính xác vì nó bỏ qua bối cảnh.
- Ưu điểm:Dễ hiểu đối với các bên liên quan.
- Nhược điểm:Bỏ qua sự khác biệt cá nhân về kỹ năng và kinh nghiệm. Khuyến khích tập trung vào thời gian thay vì giá trị.
Ước lượng tương đối
Ước lượng tương đối so sánh một nhiệm vụ với nhiệm vụ khác. Thay vì nói ‘việc này sẽ mất 4 giờ’, bạn có thể nói ‘việc này khó gấp đôi nhiệm vụ kia’. Đây là tiêu chuẩn trong các đội Scrum.
- Ưu điểm:Giảm tải nhận thức. Tập trung vào độ phức tạp và nỗ lực thay vì thời gian.
- Nhược điểm:Các bên liên quan có thể thấy khó chuyển đổi sang ngày trên lịch.
Hầu hết các đội Agile đều ưu tiên ước lượng tương đối vì nó tính đến bối cảnh riêng biệt của đội nhóm. Điều này cho phép bạn tận dụng kinh nghiệm quá khứ mà không cần phải dự đoán tương lai bằng đồng hồ bấm giây.
Poker lập kế hoạch: Tiêu chuẩn vàng 🃏
Planning Poker là kỹ thuật được sử dụng rộng rãi nhất cho việc ước lượng hợp tác. Nó kết hợp suy nghĩ cá nhân với thảo luận nhóm để đạt được sự đồng thuận. Dưới đây là cách quy trình thường diễn ra trong buổi lập kế hoạch sprint:
- Xem lại câu chuyện người dùng:Đội đọc mô tả và các tiêu chí chấp nhận cùng nhau.
- Đặt câu hỏi:Các nhà phát triển đặt câu hỏi làm rõ để đảm bảo mọi người hiểu đúng phạm vi.
- Lựa chọn riêng tư:Mỗi nhà phát triển chọn một lá bài đại diện cho ước lượng của mình mà không cho người khác thấy.
- Bật mí đồng thời:Mọi người cùng bật mí lá bài của mình.
- Thảo luận:Nếu các ước lượng chênh lệch đáng kể, những người đưa ra ước lượng cao nhất và thấp nhất sẽ giải thích lý do của mình.
- Bỏ phiếu lại:Đội bỏ phiếu lại cho đến khi đạt được sự đồng thuận.
Kỹ thuật này ngăn chặn hiện tượng ‘chệch hướng do điểm khởi đầu’, khi ý kiến của một người ảnh hưởng đến nhóm trước khi mọi người suy nghĩ độc lập. Nó đảm bảo rằng những tiếng nói lặng lẽ nhất cũng được lắng nghe cùng với những tiếng nói sôi nổi nhất.
Dãy Fibonacci được giải thích 🔢
Bạn sẽ nhận thấy rằng các lá bài Planning Poker thường sử dụng các con số 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 và 120. Điều này dựa trên dãy Fibonacci. Tại sao không dùng 1, 2, 3, 4, 5? Toán học đằng sau điều này đơn giản nhưng sâu sắc.
Khi kích thước của một nhiệm vụ tăng lên, mức độ không chắc chắn cũng tăng theo. Một nhiệm vụ 1 điểm là đơn giản và dễ dự đoán. Một nhiệm vụ 13 điểm có rất nhiều điều chưa biết. Bằng cách bỏ qua các con số, chúng ta công nhận rằng sự chênh lệch giữa 5 và 8 lớn hơn nhiều về mặt rủi ro so với sự chênh lệch giữa 2 và 3.
- Các con số nhỏ (1-5):Đại diện cho các nhiệm vụ được hiểu rõ và ít rủi ro.
- Các con số trung bình (8-13):Chỉ ra mức độ phức tạp trung bình kèm theo một số điều chưa biết.
- Các con số lớn (21+):Ngụ ý rằng câu chuyện quá lớn và cần được chia nhỏ thành các phần nhỏ hơn.
Việc sử dụng dãy này giúp đội tránh được sự chính xác giả tạo khi nói rằng điều gì đó sẽ mất đúng 7 ngày. Nó khuyến khích suy nghĩ theo các nhóm công sức thay vì theo giờ chính xác.
Kích cỡ áo phông cho ước lượng cấp cao 👕
Đôi khi, bạn đang ước lượng ở cấp độ tính năng thay vì cấp độ câu chuyện người dùng. Trong những trường hợp này, Planning Poker có thể quá chi tiết. Kỹ thuật Kích cỡ áo phông là một phương pháp tuyệt vời cho việc lập kế hoạch cấp cao.
Thay vì dùng con số, bạn dùng các kích cỡ như XS, S, M, L, XL và XXL. Phương pháp này thường được dùng trong việc tinh chỉnh danh sách công việc để ưu tiên công việc trước khi nó bước vào một sprint.
| Kích cỡ | Ý nghĩa | Tương đương điểm câu chuyện thông thường |
|---|---|---|
| XS | Rất nhỏ, nỗ lực nhỏ bé | 1 |
| S | Những thay đổi nhỏ, đơn giản | 2-3 |
| M | Nỗ lực trung bình, độ phức tạp vừa phải | 5 |
| L | Nỗ lực lớn, đòi hỏi nhiều ngày | 8 |
| XL | Rất lớn, rủi ro cao | 13+ |
| XXL | Quá lớn, phải chia nhỏ | Epic |
Phương pháp này mang tính trực quan và thú vị, giúp thu hút toàn bộ đội nhóm. Nó đặc biệt hữu ích khi bạn chưa có đủ chi tiết để gán điểm câu chuyện cụ thể.
Ước lượng và nhóm theo tính tương đồng 📦
Ước lượng theo tính tương đồng là một phương pháp được dùng để nhanh chóng nhóm các mục tương tự lại với nhau. Phương pháp này thường được dùng khi bạn có danh sách công việc lớn và cần xác định kích thước cho nhiều mục trong thời gian ngắn.
Quy trình bao gồm:
- Tạo một câu chuyện tham chiếu: Đội nhóm thống nhất một câu chuyện đại diện cho nỗ lực “5”.
- Nhóm: Các nhà phát triển xếp các câu chuyện vào từng đống dựa trên mức độ so sánh với câu chuyện tham chiếu.
- Tinh chỉnh: Sau khi nhóm xong, đội nhóm gán điểm cho từng đống.
Phương pháp này hiệu quả với danh sách công việc lớn. Nó giúp giảm thời gian dành cho việc thảo luận chi tiết từng mục. Tuy nhiên, nó hoạt động tốt nhất khi đội nhóm có sự hiểu biết chung về nội dung câu chuyện tham chiếu.
Tốc độ và khả năng dự đoán 📈
Một khi bạn đã thực hiện ước lượng trong vài đợt sprint, bạn sẽ bắt đầu nhận thấy một mẫu hình. Điều này được gọi là Tốc độ. Tốc độ là lượng công việc mà một đội hoàn thành trong một đợt sprint, được đo bằng điểm truyện.
- Theo dõi Tốc độ:Cộng dồn điểm của tất cả các truyện đã hoàn thành vào cuối một đợt sprint.
- Tính trung bình:Xem xét 3 đến 5 đợt sprint gần nhất để tìm ra tốc độ trung bình.
- Lên kế hoạch:Sử dụng tốc độ trung bình này để quyết định số điểm cần cam kết trong đợt sprint tiếp theo.
Tốc độ không phải là chỉ số hiệu suất để đánh giá cá nhân. Đó là công cụ lập kế hoạch cho cả đội. Nếu một lập trình viên mới luôn ước lượng thấp, đội có thể cung cấp hỗ trợ và huấn luyện. Nếu tốc độ thay đổi thất thường, có thể cho thấy đội đang nhận quá nhiều công việc hoặc yêu cầu đang thay đổi thường xuyên.
Những sai lầm phổ biến đối với người mới ⚠️
Ngay cả với các kỹ thuật tốt nhất, việc mắc sai lầm vẫn rất dễ xảy ra. Việc nhận thức được những sai lầm phổ biến này sẽ giúp bạn tránh được chúng.
- Ước lượng dựa trên tình huống tốt nhất:Không bao giờ ước lượng cho tình huống hoàn hảo. Luôn tính đến các lỗi, kiểm tra mã nguồn và các vấn đề bất ngờ.
- Bỏ qua các phụ thuộc:Nếu công việc của bạn phụ thuộc vào một đội khác hoặc một API chưa sẵn sàng, ước lượng của bạn sẽ sai. Hãy làm rõ điều này.
- Nhầm lẫn giữa viết mã và triển khai:Việc ước lượng bao gồm thiết kế, viết mã, kiểm thử và tài liệu. Đừng chỉ tính thời gian viết mã.
- Sợ nói ‘Tôi không biết’:Tốt hơn hết là ước lượng thận trọng và xin giúp đỡ hơn là hứa quá nhiều và trễ hạn.
Minh bạch là chìa khóa. Nếu bạn cảm thấy không chắc chắn về một truyện, hãy bỏ phiếu cao. Tốt hơn là có một ước lượng hơi cao hơn là thất bại trong việc giao hàng.
Những câu hỏi cần đặt ra trước khi ước lượng ❓
Trước khi bạn chọn một thẻ hoặc gán một con số, hãy hỏi đội những câu hỏi này. Chúng sẽ giúp bạn phát hiện ra sự phức tạp ẩn giấu.
- ‘Hoàn thành’ có nghĩa là gì?Xem lại Định nghĩa Hoàn thành của đội.
- Có trường hợp biên hay không?Liệu điều này có xử lý các trạng thái lỗi hoặc hành vi người dùng cụ thể không?
- Môi trường đã sẵn sàng chưa?Chúng ta có cần thiết lập hạ tầng hoặc cơ sở dữ liệu mới không?
- Ai khác đang tham gia?Chúng ta có cần sự hỗ trợ từ các nhà thiết kế, QA hay kỹ sư backend không?
- Tiêu chí chấp nhận có rõ ràng không?Nếu bạn phải đoán, câu chuyện chưa sẵn sàng.
Việc đặt những câu hỏi này cho thấy sự tham gia và tư duy phản biện. Nó cũng giúp Người sở hữu Sản phẩm nhận ra rằng một câu chuyện cần thêm chi tiết trước khi có thể ước lượng chính xác.
Tóm tắt bảng Kỹ thuật 📊
Dưới đây là hướng dẫn tham khảo nhanh để giúp bạn chọn đúng kỹ thuật cho tình huống.
| Kỹ thuật | Dùng tốt nhất cho | Độ phức tạp | Thời gian cần thiết |
|---|---|---|---|
| Poker lập kế hoạch | Câu chuyện người dùng cụ thể | Trung bình | 5-10 phút mỗi câu chuyện |
| Phân loại theo cỡ áo thun | Tính năng hoặc các mục lớn | Thấp | 1-2 phút mỗi mục |
| Ước lượng theo nhóm | Tinh chỉnh danh sách công việc lớn | Thấp | Buổi nhóm |
| Hệ thống thùng | Phân loại nhanh ở cấp độ cao | Thấp | Rất nhanh |
| Giờ | Bối cảnh không Agile | Cao | Thay đổi |
Hãy nhớ rằng công cụ quan trọng hơn cuộc trò chuyện. Mục tiêu là đạt được sự hiểu biết chung về công việc.
Tiến bước với sự tự tin 🏁
Ước lượng là một kỹ năng được cải thiện qua thực hành. Là một lập trình viên cấp dưới, đừng mong đợi sẽ hoàn hảo ngay từ lần đầu tiên. Mục tiêu là trở nên tốt hơn theo thời gian.
- Tham gia vào buổi họp rút kinh nghiệm: Thảo luận về độ chính xác của việc ước lượng trong các buổi họp rút kinh nghiệm.
- Xin phản hồi:Hỏi các lập trình viên cấp cao vì sao họ chọn một con số cụ thể.
- Theo dõi quá trình học tập của bạn:Ghi chép lại các câu chuyện bạn đã ước lượng và so sánh với kết quả thực tế.
- Giữ bình tĩnh:Nếu ước lượng sai, hãy phân tích lý do. Đó là cơ hội học hỏi, chứ không phải thất bại.
Bằng cách áp dụng những kỹ thuật này và duy trì tư duy cởi mở, bạn sẽ đóng góp hiệu quả hơn cho đội Scrum của mình. Bạn sẽ giúp xây dựng văn hóa dự đoán được và tin cậy. Đây là nền tảng của một môi trường Agile thành công.
