User story point, velocity và lập kế hoạch phát hành

Trong bài trước (http://www.hanoiscrum.net/hnscrum/learning/102) tôi đã giới thiệu “User Story là gì”. Hiểu được và thao tác được với user story thì mới mong lập kế hoạch hiệu quả được .

Lập kế hoạch tức là phải phác thảo ra được lượng nỗ lực và nguồn lực cần thiết bỏ ra trong khoảng thời gian nhất định để đạt được mục đích. Để làm được việc lập kế hoạch thì chắc chắn phải ước lượng. Nhưng ước lượng là một bài toán khó, vì đòi hỏi đoán trước tương lai. Bản chất từ “ước lượng” đã hàm ý việc không thể đòi hỏi tính chính xác 100% trong các giá trị được đưa ra. Tuy vậy, về tính “hữu ích” và thực tế, chúng ta luôn phải tìm kiếm một phương pháp ước lượng đáng tin cậy.

Trong bài “Tại sao point lại tốt hơn giờ?” (http://www.hanoiscrum.net/hnscrum/resource/109), Jeff Sutherland đã chỉ ra ưu điểm của user story point. Bài này muốn đóng góp thêm vài ý.

1. User Story point là gì?

Đó là đại lượng chỉ độ lớn tương đối của các user story trong cùng một dự án. Trong một phiên hoạch định trước Sprint, nhóm phát triển dùng Scrum Poker để đánh giá độ lớn bé các story này, và ghi các giá trị đó lên mỗi user story card.

Ví dụ ta phải làm một hệ thống có ba user story như sau:

u1. là khách hàng, tôi muốn đăng nhập vào hệ thống để xem trạng thái cua đơn hàng đã đặt.

u2. là khách hàng, tôi muốn lựa chọn các sản phẩm mong muốn vào giỏ hàng để đặt mua

u3. là khách hàng, tôi muốn hủy một đơn hàng khi đã đặt

u1 được gán là 3 điểm (point), u2 là 8, u3 là 4 tức là độ lớn của toàn bộ dự án là 15 điểm. Nỗ lực cần bỏ ra để thực hiện u3 tương đương u1, u2 gấp đôi u1. Ở đây dấu “=” có nghĩa là “khoảng ấy”, cỡ ấy chứ không hàm ý là “bằng”.

2. Độ lớn của các story có thể thay đổi theo thời gian

Do nhóm đã trưởng thành qua thời gian, hiểu biếu về hệ thống thay đổi, và có thể PO thay đổi yêu cầu v.v., nên phải tái ước lượng. Vì thế u3 có thể được đánh giá lại sau sprint 1 là 6 thay vì 4 như cũ vì có vẻ việc hủy một đơn hàng không đơn giản là nhấn nút “Hủy” mà còn phải tính tới các chính sách khác chưa được tính tới tại thời điểm ước lượng lần một. Vì thế sau phiên “làm mịn” các story, thì độ lớn của từng story thay đổi.

Nhưng ..

3. Story point là đơn vị cố định. Nó là atomic.

Không có chuyện một point ở Sprint 2 thì bằng một nửa point ở Sprint 1. Chỉ có việc u3 ở Sprint 2 có thể được ước lượng lại ở Sprint 2 là tăng lên 6 points.

Tất cả các point đều phải quy chiếu về cái gì đó làm mẫu. Ví dụ, lúc đầu, tất cả các story u2, u3, .. đều được mang ra so sánh với u1. Thì đến Sprint 3,story  Un cũng phải đem ra so sánh với u1. Nếu không tham chiếu đến “tiêu chuẩn”, thì khái niệm “point” không có giá trị gì trong hoạch định dài hạn cả.

Agile Estimation (Ước lượng Linh hoạt):

1. Lấy ra một cặp story (ví dụ: u1 và u3) tương đối dễ hiểu đối với cả nhóm (hiểu cả nghiệp vụ lẫn các công việc để thực hiện hai story này); story thứ hai có độ lớn gấp đôi story kia.

2. Gán u1 số điểm là 3, u3 là 8. Hai story này để tham chiếu cho toàn bộ quá trình ước lượng các story còn lại.

3. Chơi Scrum Poker để đánh giá độ lớn các story còn lại.

Việc so sánh độ lớn của một story u3 ở Sprint 1 với Sprint 2 là không có ý nghĩa gì cả. Cái này nó biến động liên tục. Vì nó không có nghĩa nên không nên đem ra so sánh để làm gì.

4. Velocity (tốc độ) là gì?

Là số point burn được trong một Sprint.

Velocity có thể thay đổi theo thời gian. Thường là tăng.

Với giả định là các ước lượng user story point ban đầu là đáng tin thì có vẻ như velocity sẽ tăng dần do nhóm ngày càng làm việc tốt hơn, hiểu sản phẩm hơn, nắm vững công nghệ đặc thù của bài toán đó hơn v.v.

Khái niệm gia tốc có thể được tính đến khi nhóm scrum ở mức trưởng thành cao. Khi đó tốc độ tăng tiến đều và đoán được thông qua một đại lượng cố định. V2=aV1.  Tuy vậy, giá trị này không phải lúc nào cũng có nghĩa.

5. Velocity có giá trị đối với việc hoạch định sản phẩm và phát hành

Giả sử nhóm là cố định. Hiệu suất của nhóm được đo bằng velocity. Giá trị này hoàn toàn tiên lượng được trong ngắn hạn.

Giả sử Sprint 1 burn được 30 point, Sprint 2 được 35 point, thì có vẻ như Sprint 3 nhóm sẽ burn được ít nhất là 35 point. Điều này là tin được, vì theo (4), nhóm sẽ làm việc ở Sprint 3 không kém hơn so với Sprint trước.

Chuyện tiên lượng này không hề bị ảnh hưởng của sự ước lượng lại tại đầu Sprint (khi đó u3 có thể đã có độ lớn bằng gấp đôi so với ước lượng lần trước). Vì sau khi làm mịn, độ lớn lại được quy ra point, và point này là lại quy về point so với thời điểm ban đầu (so với u1).

Do vậỵ Product Owner hoàn toàn có thể đoán được thời điểm một feature nào đó sẽ có (để quảng cáo, bán hàng, v.v.) cũng như phác ra một kế hoạch release khả thi.

6. Velocity không phải là công cụ đo performance của các nhân

Mặc dù ta có thể làm như vậy, và thực tế nhiều người làm như thế. Trong một nhóm có thể có quy ước “ghi công” cho ai đó khi hoàn thành một feature. Khi đó cuối Sprint ta biết được ai burn được bao nhiêu để lập “bảng thành tích” rồi “tính lương” Smile.

Một số dự án đặc thù có thể cho phép cách làm như vậy. Nhưng đại thể, agile không khuyến khích cách làm như vậy. Agile vốn khuyến khích tương tác, cộng tác, sở hữu tập thể thì không có lí gì lại đi đo thành tích cá nhân dựa trên số point burn được của từng cá nhân. Cái này là scrumbut.

7. Quy đổi ra giờ

Cuối cùng thì ai cũng hỏi vậy tương đương Point-Giờ thế nào? Vì cái làm việc theo giờ thì dễ hình dung hơn về độ lớn của dự án. Chứ point “ảo” quá! Quy ra person-month hộ tôi cái!!! Winking smile

Chỉ có mối tương quan point-giờ trong phạm vi dự án mà thôi do point là chỉ là đơn vị có giá trị trong nội bộ một dự án. Point trong dự án này không bằng point trong dự án khác (do quy chiếu khác nhau).

Cách quy đổi khá dễ: nếu nhóm năm người burn được 30 point trong 1 sprint 1 tháng, thì rõ ràng là một point bằng năm person-month rồi. Tuy nhiên bản thân độ đo user story point đã đủ tốt rồi, nếu không phải trường hợp vạn bất đắc dĩ, không việc gì phải dùng thêm một độ đo khác vốn cực kì bất ổn là person-month (cái này thì sách nói nhiều rồi).

8. Dùng point cho story, nhưng dùng “giờ” cho task

Khi PO quyết định nhóm phải burn 30 point trong Sprint tới với các story được chọn lựa thì việc của nhóm là phải break down các Story kia thành ra các task với ước lượng ra “giờ” để điền vào Sprint Backlog. Trong trường hợp này, nhóm lại quên khái niệm point đi (thực ra khái niệm này có nghĩa với PO hơn là với dev), để tập trung việc burn được bao nhiêu productive hours.

Sự nhầm lẫn hay xảy ra khi nhóm vẫn dùng Scrum Poker để ước lượng các task nhưng lại nghĩ là mình ước lượng các story. Để tránh nhầm lẫn nầy, không nên để hai phiên làm việc release planning (đánh giá story) liền với Sprint Planning (chẻ nhỏ story).

Advertisements

2 Comments

  1. Hi anh,

    Đọc xong vẫn băn khoăn thế làm thế nào để xác được được số Point trong 1 Sprint. Vì anh cũng có nói point là cố định, vậy thì cố định là cố định theo cái gì. Anh xác đinh point, có phải team tự ngồi với nhau và xác định với nhau không ah.

    Nếu tiện thì khi nào anh có thể viết nhật ký Scrum và cách ứng dụng các Tool trong Scrum vào thực tiễn bên anh để mọi người tham khảo.

    Cảm ơn anh.

    1. 1. Cái ý point cố định, tức là đơn vị thì không đổi theo thời gian. Giống như đơn vị là mét (m) thì qua thời gian 1m vẫn là 1m chứ không phải là sau một năm thì 1m của năm ngoái nay chỉ còn 0.5m. Sở dĩ phải nhấn mạnh điều này vì có người có ý định “quy đổi point”, tức là thay đổi đơn vị đo. Khi đó thì mất đi giá trị “đơn vị” của khái niệm “point”, làm mất đi giá trị sử dụng của nó.

      Chứ không phải mỗi Sprint đều burn một số point cố định 🙂

      2. Việc ghi nhật kí: “cuốn nhật kí vĩ đại” “Scrum and XP from the trenches” –( Scrum và XP từ chiến hào) đang được dịch và sẽ đăng dần lên HanoiScrum.net. Nửa cuốn đã được dịch, chờ hiệu đính là cuối tuần sau có thể “lên sàn”. CanhPX đón đọc nhé 😉

      3. Cách xác định số point trong 1 Sprint: = số point đã burnt ở Sprint trước + một số point nữa (theo gia tốc). Cái khó là việc xác định ở Sprint đầu tiên.
      Ở lần đầu tiên (giả sử chưa có bất kì kinh nghiệm agile estimation nào trước đó) thì khó hơn một chút:
      i. Ở phiên làm việc requirement (có thể là user story writing workshop, hoặc sau đó – nhưng trước khi Sprint Planning Meeting diễn ra). Cả nhóm sẽ ước lượng các user story ra point.
      ii. Ở Planning Meeting cho Sprint 1, nhóm sẽ PO sẽ chọn các story có độ ưu tiên cao nhất.
      iii. DevTeam tính Capacity của mình. Có bao nhiêu thời gian development (gọi là production hours) — trừ đi các thời gian overhead khác (báo cáo, họp, ăn uống, giải lao v.v.)
      iv. DevTeam không cần quan tâm tới point làm gì, phân tích các story, bẻ nhỏ thành các task cần thiết để làm trong Sprint 1.
      v. Trong quá trình breaking down đó, nhóm ước lượng công việc cho từng task ra giờ (nhỏ hơn 8h/task, nên <4h nếu có thể). Cộng dồn lại, nếu bằng Capacity thì dừng lại. Khi đó nhóm sẽ biết mình cần phải làm bao nhiêu việc trong Sprint 1.
      vi. ProductOwner tính xem DevTeam vừa chọn bao nhiêu point dựa trên số story đã chọn. Đơn giản là cộng các point ghi trên mỗi story lại là xong. PO ghi lại ước lượng đó vào Product Backlog, Release Backlog và Release Burndown (để quản lí về sau).
      vii. Sau khi Sprint 1, đánh giá lại xem việc chọn việc có ổn không và điều chỉnh số point cho Sprint 2 như đã nói ở phần trên.

Trả lời

Mời bạn điền thông tin vào ô dưới đây hoặc kích vào một biểu tượng để đăng nhập:

WordPress.com Logo

Bạn đang bình luận bằng tài khoản WordPress.com Đăng xuất / Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Đăng xuất / Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Đăng xuất / Thay đổi )

Google+ photo

Bạn đang bình luận bằng tài khoản Google+ Đăng xuất / Thay đổi )

Connecting to %s