Trong khi thực hiện một dự án Agile, nhóm lên kế hoạch làm việc cho các lần chạy nước rút sắp tới bằng cách tạo ra các câu chuyện. Lịch sử xác định một hoạt động đơn lẻ được đóng theo chức năng cùng với mô tả và tiêu chí chấp nhận.
Chạy nước rút thường kéo dài từ hai đến bốn tuần. Trong thời gian này, nhóm cần hiểu họ có thể đưa bao nhiêu nội dung vào một lần chạy nước rút để vẫn có thể thực hiện được trong thời gian chạy nước rút đã chỉ định.
Đối với một dự án không linh hoạt, bạn sẽ ước tính công việc thường tính theo ngày công. Tức là bạn cần bao nhiêu nhân viên toàn thời gian để thực hiện hoạt động này? Trong trường hợp này, khi tạo ước tính, bạn luôn nghĩ đến ngày và số lượng người.
Trong các dự án linh hoạt, tình hình lại khác. Bạn không còn đếm số ngày hoặc số người để tính toán ước tính cuối cùng của mình. Trên thực tế, chúng tôi thậm chí còn cấm tính nỗ lực vào những thứ như ngày công. Thay vào đó, bạn để nhóm chuyển đổi thành một giá trị được chấp nhận chung cho câu chuyện sẽ thể hiện ước tính tổng thể.
Bây giờ, giá trị chính xác là gì, nó không thực sự quan trọng. Đúng, đại diện phổ biến nhất cho ước tính câu chuyện là Điểm câu chuyện. Về cơ bản đây là những số Fibonacci bắt đầu bằng 0, 1, 2, 3, 5, 8, 13, 21, v.v. Giá trị tiếp theo là tổng của hai số trước đó. Điều này sẽ giúp phân biệt mức độ phức tạp tổng thể của câu chuyện vì mỗi số cao hơn liên tiếp đều cao hơn nhiều so với số trước.
Nhưng bạn không cần phải bám vào các điểm trong câu chuyện. Đây có thể là các kích cỡ áo phông ước tính (XXS, XS, S, M, L, XL, XXL). Nếu muốn thực sự sáng tạo, bạn có thể mang các loài động vật trong vườn thú đến và sử dụng chúng để ước tính kích thước.
Dù bằng cách nào, giờ đây nhóm phụ thuộc nhiều vào cảm nhận của nhóm về việc con số (hoặc con vật) nào nắm bắt tốt nhất sự phức tạp tổng thể của câu chuyện cụ thể này. Nó chắc chắn không phải là về đại diện thời gian. Cuối cùng, nhóm phải hoàn thành mọi câu chuyện được đưa vào một lần chạy nước rút trong lần chạy nước rút đó. Vì vậy, thời gian đã được đưa ra ngay từ đầu và là một số không đổi.
Các thành phần ước tính điểm câu chuyện
Việc ước tính điểm của câu chuyện hoàn toàn không chỉ là mức độ phức tạp/khó khăn của câu chuyện. Khi ước tính lịch sử, nhóm nên xem xét một số khía cạnh và phản ánh chúng trong giá trị cuối cùng của ước tính.
Đánh giá cuối cùng khi đó là một giá trị thể hiện sự kết hợp của tất cả các khía cạnh được tạo thành một con số duy nhất. Đây là những gì một định giá như vậy nên bao gồm.
# 1. Khó khăn kỹ thuật
Giả sử chúng ta đang ước tính các câu chuyện cho nhóm phát triển thì độ khó kỹ thuật của câu chuyện sẽ là một trong những lĩnh vực đầu tiên mà nhóm sẽ tập trung vào theo mặc định.
Và đây hoàn toàn là cách tiếp cận đúng đắn. Một nhóm gồm nhiều chuyên gia kỹ thuật nên biết cách đánh giá tốt nhất một lĩnh vực lịch sử như vậy. Tại đây, nhóm có thể xem xét các cách tiếp cận hoặc mẹo khác nhau, chẳng hạn như:
- Câu chuyện này so với những câu chuyện khác đã được cung cấp như thế nào về độ phức tạp kỹ thuật?
- Nhóm sẽ cần tạo/cập nhật bao nhiêu tệp mã để hoàn thành câu chuyện?
- Lịch sử này sẽ tạo ra bao nhiêu thay đổi mã bổ sung trong các quy trình hệ thống xung quanh?
- Thuật toán hoặc logic quy trình sẽ được triển khai phức tạp đến mức nào?
#2. Sự phụ thuộc và mối đe dọa bên ngoài
Bạn có thể ngạc nhiên, nhưng thường thì sự thành công của một câu chuyện trong một cuộc chạy nước rút của nhóm phụ thuộc vào ý kiến đóng góp của các nhóm khác hoặc những người bên ngoài nhóm.
Những câu chuyện mà mọi thứ mà nhóm có thể làm một mình là dễ định lượng nhất. Mọi thứ trở nên phức tạp nếu nhóm cần sự trợ giúp từ bên ngoài cho câu chuyện của họ. Đối với những người ngoài nhóm, hoạt động này tất nhiên sẽ không được ưu tiên. Nhóm chỉ cần dựa vào yếu tố này và đưa nó vào ước tính.
Yếu tố này sẽ tăng tổng ước tính lên bao nhiêu sẽ phụ thuộc chủ yếu vào kinh nghiệm trước đây của nhóm và “mức độ ngoại ứng”. Thông thường trong một số lần chạy nước rút, nhóm thiết lập một số ý thức thống nhất, tự nhiên về mức độ phụ thuộc vào người ngoài này có thể làm phức tạp việc hoàn thành thành công câu chuyện đến mức nào.
#3. Yếu tố tái sử dụng
Lĩnh vực tiếp theo cần xem xét là nhóm có thể sử dụng lại bao nhiêu nội dung hiện có để hoàn thành câu chuyện. Tất nhiên, nếu một số bộ phận đã có sẵn theo cách này hay cách khác thì không cần thiết phải xây dựng chúng từ đầu. Thay vào đó, nhóm có thể sử dụng lại giải pháp đã tạo để xây dựng giải pháp mới nhanh hơn nhiều.
Bằng cách này, kiến thức này có thể hạ thấp tổng ước tính, ngay cả khi thông thường (không thể sử dụng lại) câu chuyện sẽ phức tạp hơn dựa trên nội dung đã xác định.
#4. Hiểu nhóm của riêng bạn
Một yếu tố đáng chú ý mà không có ước tính ngày công nào tính đến là sự tự nhận thức của nhóm về thâm niên và năng lực.
Khi nhóm làm việc cùng nhau và thực hiện một số lần chạy nước rút, những người ở giữa sẽ làm quen với nhau. Họ sẽ bắt đầu hiểu ai biết được điều gì và anh ta giỏi việc đó như thế nào. Và một khi mọi người đã biết về phần còn lại của nhóm, họ có thể tính đến điều đó như một nhóm khi ước tính.
Nếu câu chuyện dựa vào các kỹ năng kỹ thuật cụ thể và kỹ năng đó hiện diện rất nhiều trong nhóm thì rõ ràng việc hiện thực hóa câu chuyện này sẽ không gặp nhiều rắc rối. Hoặc ngược lại, nếu toàn bộ nhóm thiếu các kỹ năng cần thiết, nhóm sẽ cần nhiều thời gian hơn để đi sâu vào chủ đề và nên phản ánh điều này trong ước tính.
Lịch sử ước tính
Mỗi bài đánh giá câu chuyện phải là nỗ lực của cả nhóm. Không một giọng nói nào có thể xác định trước sự phức tạp của câu chuyện. Mục tiêu cuối cùng là cho phép nhóm thảo luận về ước tính cho đến khi tất cả các thành viên đồng ý về một giá trị duy nhất đại diện cho ước tính cuối cùng.
Nhóm có thể đưa ra ước tính trực tiếp trong Cuộc thảo luận cải tiến Sprint (cuộc họp nơi các nhóm thảo luận và giải thích các câu chuyện) hoặc cách khác, họ có thể dành thời gian đặc biệt cho việc này.
Ví dụ về quy trình ước tính
Cam kết kế hoạch Sprint
Nhóm hiện có một lượng tồn đọng các câu chuyện đã trải qua các phiên ước tính. Tốt nhất, các story cũng nên được ưu tiên (ngoài ước tính cuối cùng) để nhóm biết story nào sẽ xuất hiện tiếp theo trong sprint tiếp theo.
Một phiên lập kế hoạch sắp diễn ra và nhóm sẽ chọn một số câu chuyện cho lần chạy nước rút tiếp theo. Việc quyết định chọn câu chuyện nào nên dựa trên những cân nhắc sau:
✅ Những câu chuyện có mức độ ưu tiên cao nhất sẽ được nhóm xem xét trước.
✅ Nhóm trải nghiệm xem họ có thể hoàn thành bao nhiêu điểm câu chuyện trong một lần chạy nước rút. Kiến thức này đi kèm với thời gian và kinh nghiệm của nhóm. Bạn cần một vài lần chạy nước rút để tinh chỉnh và hiểu đúng về khả năng này.
✅ Không chỉ cần xem xét tổng số điểm câu chuyện và mức độ ưu tiên. Một vấn đề khác là các kỹ năng trong nhóm sẽ lan tỏa như thế nào trên các câu chuyện đã chọn. Ví dụ: nếu một nhóm chỉ có hai nhà phát triển front-end, họ không thể chỉ chọn những câu chuyện hoàn toàn bao gồm phát triển front-end. Điều này sẽ dẫn đến việc sử dụng quá mức hai người trong khi những người còn lại trong đội thì không nhiều. Như vậy, kiến thức của nhóm đi đôi với hiệu quả của việc tạo nội dung chạy nước rút.
Hệ số tốc độ
Trước hết, điều quan trọng là tốc độ của toàn đội (xét về chặng chạy nước rút sắp tới). Con số này không hề liên quan đến tổng số điểm của câu chuyện. Tuy nhiên, nó cho biết nhóm sẽ sẵn sàng làm việc ở mức độ nào trong lần chạy nước rút sắp tới.
Để có thể lên kế hoạch chính xác cho nội dung của sprint, chúng tôi đã kết hợp cả hai khía cạnh:
Việc tìm kiếm ý nghĩa vàng cần có thời gian và thực hành.
Lợi ích và những lỗi thường gặp
Điều đáng ngạc nhiên là các nhóm sẵn sàng làm phức tạp quy trình khi họ chuyển sang một nhóm linh hoạt. Theo nghĩa đen, có vẻ như bạn phải “hiểu rõ” trước khi bắt đầu làm việc ở chế độ này.
Thật không may, bước đầu tiên này cũng là bước khó nhất. Trong một số trường hợp, thậm chí phải mất nhiều năm, đặc biệt là trong môi trường doanh nghiệp bảo thủ nghiêm ngặt, nơi thời gian bị mắc kẹt trong thời gian.
Trong mọi trường hợp, điều này sẽ xảy ra khi nhóm “hiểu được” điều này:
- Bạn không còn cần phải đếm số người hay số ngày để biết khi nào có thể hoàn thành một việc gì đó.
- Nhóm sẽ học cách tạo ra những câu chuyện chỉ đủ phức tạp để phù hợp với một cuộc chạy nước rút. Nếu câu chuyện phức tạp hơn, nó sẽ tự động được chia thành nhiều câu chuyện hơn.
- Nhóm có những ước tính tốt cho từng phần công việc và khi họ lên lịch cho một lần chạy nước rút, bạn sẽ biết chính xác khi nào đến hạn.
- Điều này sẽ làm tăng độ tin cậy và khả năng dự đoán của nhóm.
- Tất cả những người trong nhóm sẽ được “phát sóng trên cùng một tần số”. Họ sẽ nhìn vào lịch sử và hiểu những điều tương tự. Có lẽ sau một thời gian họ thậm chí không buồn ước tính. Họ nhìn thấy con số trong đầu và vì mọi người đều nhìn thấy con số giống nhau nên họ có thể tham gia vào các câu chuyện chạy nước rút ngay cả khi không có ước tính rõ ràng đó.
Đây là điều thường xảy ra khi nhóm vẫn chưa thể hiểu được quy trình hoặc cách làm việc:
- Bằng cách nào đó họ vẫn tuân theo những ước tính về ngày công lỗi thời. Họ chuyển đổi mọi thứ thành ngày hoặc những người có liên quan. Điểm lịch sử hoặc số Fibonacci biểu thị số ngày trực tiếp hoặc gián tiếp thông qua các phép biến đổi khác nhau.
- Lãnh đạo so sánh các nhóm dựa trên số điểm câu chuyện được giao trong mỗi lần chạy nước rút. Điều này thật sai lầm. Sau đó, một thực tế quan trọng vẫn chưa được hiểu: mỗi đội đánh giá các điểm câu chuyện một cách khác nhau. Hoàn toàn không có lý do gì để phải nỗ lực đồng bộ hóa hai đội để đánh giá câu chuyện của họ “giống nhau”.
- Mặc dù điểm cốt truyện của một đội có nghĩa là vẽ một vòng tròn, nhưng đối với đội khác, điều đó có thể có nghĩa là vẽ một ngôi nhà có mái bằng, bốn cửa sổ và hai cửa ra vào. Và nó hoàn toàn ổn.
- Đôi khi các đội có xu hướng ước tính hầu hết mọi thứ từ hai đến bốn con số khác nhau. Có lẽ vì sợ câu chuyện có số 123 nên sẽ có người cho rằng có liên quan gì đó đến số ngày. Nhưng sự thật là thang Fibonacci có vô số con số. Chúng ta không phải giới hạn bản thân trong việc ước tính 3, 5 hoặc 8. Chúng tôi chắc chắn có thể (và có thể chúng tôi đã nghĩ đến điều này rồi, trong trường hợp đó thì không sao), nhưng chúng tôi chắc chắn không cần phải làm vậy.
- Việc ước tính được hướng dẫn bởi những người lớn tuổi, những người sẽ xác định trước kỳ vọng của cả nhóm. Chúng ta không bao giờ nên cho phép một thành viên trong nhóm ảnh hưởng đến việc đánh giá. Mọi người đều có quyền bình đẳng trong việc bày tỏ quan điểm của mình và được lắng nghe.
những từ cuối
Việc chuyển sang ước tính linh hoạt từ các phương pháp truyền thống hơn không phải lúc nào cũng dễ dàng và cần có sự điều chỉnh – cho cả nhóm và cấp quản lý ở trên. Để việc này có hiệu quả, cả hai bên cần hiểu rõ quy trình. Nếu một trong số họ không hiểu thì giai đoạn chuyển tiếp là một con đường khó khăn với những kỳ vọng trái ngược nhau.
Nhưng khi mọi thứ thay đổi, một số điều kỳ diệu sẽ bắt đầu xảy ra. Các nhóm sẽ có thể ước tính và lập kế hoạch công việc của mình tốt hơn, đồng thời ban quản lý sẽ có nhiều bản phát hành và kế hoạch hành động có thể dự đoán được hơn để dựa vào.
Sau đó kiểm tra các quy trình không lành mạnh có thể làm hỏng cuộc chạy nước rút của bạn.
