Chào cả nhà,
Tuần trước, tụi mình đăng bài này lên: What Are Spikes and How to Estimate Them? [https://www.reddit.com/r/agile/comments/1ald3je/what_are_spikes_and_how_to_estimate_them/?utm_source=share&utm_medium=web2x&context=3]. Mừng quá, bài này được 30.1k view và 81 share rồi. Nhưng mà cũng nhận được kha khá comment chê bai nữa. Cá nhân mình thấy có vẻ mọi người hiểu chưa hết ý đồ và cái sâu xa của bài viết. Nên là, mình muốn chia sẻ thêm bài này, nó sẽ làm rõ hơn vấn đề đó.
Bài này được đón nhận nồng nhiệt ở mọi nơi nó được chia sẻ. Thậm chí, mấy Scrum Master còn dùng nó trong team của họ nữa. Mình rất muốn chia sẻ với cả nhà và mong mọi người đọc một cách khách quan rồi cho mình ý kiến nha. Dù có khác quan điểm đi chăng nữa thì nhớ là mình vẫn là người với người, mình vẫn có thể tử tế và khiêm tốn trong cách trả lời mà vẫn giữ vững quan điểm của mình nhé.
Một Story point bằng bao nhiêu giờ làm việc?
Ban đầu, Story point được thiết kế để trừu tượng hoá. Sự trừu tượng này giúp mọi người tập trung vào công việc (kích thước, độ phức tạp, độ lớn, v.v…). Trước khi có story point (ngày xưa ấy), mọi người hay cãi nhau về giờ giấc, dẫn đến nhiều cảm xúc tiêu cực xung quanh vấn đề thời gian.
Mình kể cho cả nhà nghe một tình huống thực tế giữa sếp và mình hồi xưa (chuyện này xảy ra cách đây khá lâu rồi):
Sếp: Đây là dự án mới [giải thích tầm 3-5 phút….. Cậu làm xong trong bao lâu?
Mình: Sếp ơi, sếp vừa mới trình bày xong, cho em ít nhất một ngày để suy nghĩ đã ạ.
Sếp: Hôm nay phải có câu trả lời rồi, 3 triệu đô đang chờ đấy!
Mình: [Ngơ ngác và bực mình] Khoảng 2 năm ạ.
Sếp: [Gần như tức giận] Cậu sẽ mất việc và tôi cũng mất việc luôn!
[…cuộc tranh luận kéo dài thêm 60 phút nữa. ]
Cuối cùng:
Sếp: Vậy thì, mình thống nhất là 6 tháng nhé?
Mình: [Với vẻ mặt thất thần…] Vâng ạ.
Dự án cuối cùng hoàn thành trong 10 tháng. Chất lượng thấp, team thì nản, khách hàng thì không hài lòng…
Quay lại vấn đề chính: Khi mình học và hiểu được cách ước lượng Story Point và cách sử dụng hiệu quả, thì cùng một tình huống đó, mình lại chỉ cần thảo luận về công việc, bất cứ khi nào có sự bất đồng về ước lượng công việc lớn (ví dụ: ước lượng dự án = 300 points).
Nếu hiểu đúng và sử dụng khéo léo, story points và mối quan hệ của nó với giờ làm việc có thể là một công cụ mạnh mẽ giúp các team Agile cải thiện độ chính xác trong việc ước lượng.
Để mình giải thích điểm này (mối quan hệ giữa Story Points và Giờ làm việc) bằng một ví dụ thực tế nhé.
Trong hình mình đưa bên dưới, các bạn sẽ thấy cách các thành viên trong team có thể nhìn lại những ước lượng trước đây và liên hệ với lượng thời gian đã bỏ ra cho các story khác nhau.
Phản hồi từ dữ liệu này đã giúp team mình hiểu rõ hơn về việc ước lượng và có những cuộc thảo luận hiệu quả hơn, dẫn đến độ chính xác cao hơn trong việc ước lượng.
Cách sử dụng biểu đồ này:
Trục Y – Kích thước tương đối (Story Points)
Trục X – Thời gian (Giờ)
Sau khi hoàn thành 4-6 sprint với một team, mình sẽ vẽ biểu đồ này và tổ chức một buổi retrospective về ước lượng với team.
Dữ liệu này cho thấy những điều thú vị:
-
Một điều là các khoảng Story point (SP) khác nhau so sánh với nhau như thế nào nói chung. Các team mới thường thấy rằng khoảng SP so với giờ làm việc khá dài và có sự chồng chéo lớn giữa các khoảng SP liền kề (được đánh dấu bằng vòng tròn đỏ trong hình 1)
2. Họ cũng nhận thấy có một số story kỳ lạ – những story nằm sâu vào khoảng SP cao hơn hoặc thấp hơn. Những story này cần nhiều cuộc thảo luận hơn và cần hiểu rõ hơn. (được đánh dấu bằng vòng tròn đỏ)
3. Sau đó, team sẽ xác định những story tương tự trong các sprint sắp tới hoặc trong tương lai và thường ước lượng lại sau khi thảo luận.
4. Điều này giúp làm cho khoảng Story Point so với giờ làm việc trở nên nhỏ gọn hơn và chúng chồng chéo nhiều hơn ở các cạnh (như thể hiện bằng màu xanh lá cây trong Hình 2)
Quá trình này cần một chút nỗ lực và thời gian, nhưng mang lại những kết quả rất tốt và giúp hiểu rõ hơn về cách sử dụng story points một cách khôn ngoan và mối quan hệ của chúng với giờ làm việc.
Mình hy vọng các bạn có thể áp dụng điều này vào công việc của mình và được hưởng lợi từ nó.
