Ước tính chi phí và độ lớn của dự án theo cách của scrum

Trước tiên tôi xin lưu ý cho các bạn rằng bài viết này chỉ ra cách thức tính toán chi phí theo cách của Scrum với giả định bạn đã có sẵn một Scrum Team. Công thức này chỉ mang tính tương đối trong dự án, tất nhiên trong giai đoạn phát triển phần mềm sẽ có nhiều yếu tố ảnh hưởng đến quá trình và kế hoạch phát triển như sự biến động về nhân lực, sự thay đổi về công nghệ, về các yêu cầu của khách hàng, …

I. Dẫn nhập

• Scrum là một khái niệm rất thú vị, thực tiễn và sinh động. Tuy vậy, sách viết về Scrum ít đề cập đến những chi tiết liên quan đến tiền nong, vốn là những thứ cần thận trọng. Nên câu hỏi “làm sao để xác định giá trị hợp đồng?”, “làm sao để tính được chi phí cho dự án?” luôn là những câu hỏi làm đau đầu các nhà quản lý dự án.

• Nhiều người cho rằng ước tính hay lập kế hoạch là những kĩ năng khó khăn nhất trong thực tiễn làm dự án phần mềm. Nhiều phương án kĩ thuật đã được đưa ra và áp dụng rộng rãi như Function Points, Cocomo, … Tuy vậy, các phương pháp này có phần “không tương thích” với cách làm agile. Tôi giới thiệu một lựa chọn khác cho những người làm theo triết lí Agile, gọi là agile estimation với đơn vị đo là story point. Những người làm agile đều đánh giá đó là thước đo khả dụng, phù hợp với Agile.

• Một phương pháp ước lượng tốt khi được dùng đúng chỗ. Các tham số chính ảnh hưởng đến sự lựa chọn phương pháp ước lượng bao gồm kích thước dự án (lớn, trung bình, nhỏ) và phương pháp luận phát triển phần mềm. Sự chuyển dịch sang agile trong thời gian hơn một thập kỉ qua đồng nghĩa với việc các phương pháp ước tính bottom-up (như agile estimation chẳng hạn) được ưa thích hơn nhờ vào độ chính xác cao dựa trên dữ liệu thực nghiệm của chính dự án.

II. Nhắc lại các khái niệm cơ bản

1. User Story là gì?

• User Story là một bản tóm tắt các nhu cầu của người dùng. Thông thường, user story do khách hàng, hoặc đại diện của khách hàng – những người thực sự hiểu nghiệp vụ và nắm bắt được chính xác yêu cầu của mình đối với nhóm phát triển – cung cấp. Story không đơn thuần là công cụ requirement mà còn là công cụ để giao tiếp, chất kết dính và được ví như cái “phanh hãm” trong phát triển. Scrum quy định Product Owner sở hữu các story (thông qua product backlog), nhưng đó không phải công việc đơn thuần của Product Owner ( ví dụ như ở một vài cách làm khác, “BA làm requirement” v.v.).

2. 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.

3. Agile Estimation là gì?

• Là cách thức ước lượng độ lớn của story theo cách linh hoạt. Sử dụng Scrum Poker, nhóm sẽ đánh giá các story dựa theo sự so sánh với các story mẫu (là các story dễ hiểu đối với nhóm, gán giá trị khởi đầu để làm “mốc” đánh giá cho các story khác). Trước khi Sprint 1 diễn ra, nhóm Scrum cộng tác trong buổi họp kế hoạch phát hành (Release Planning) để xác định những tính năng nào sẽ có trong bản phát hành, thời điểm nào sẽ phát hành sản phẩm. Khi đó nhóm sẽ phải ước tính cho tất cả các story được xác định tham gia vào release tới.

4. Velocity là gì?

• Là tốc độ burn được bao nhiêu điểm (point) trong một Sprint. Ví dụ Sprint 1 nhóm burn được 45 point, Sprint 2 được 51, Sprint 3 được 48 thì tốc độ trung bình được tính:

  V = (45+51+48)/3 = 48.

  • Giả sử mọi thứ không đổi, một release được ước tính ban đầu có độ lớn 480 point thì nhóm phải trải qua khoảng 480/48 = 10 Sprint.

  • Lưu ý: velocity chỉ có giá trị tương đối, hỗ trợ việc ước tính, giá trị tuyệt đối của nó không có ý nghĩa gì. Cấp quản lí về cơ bản không thể căn cứ vào velocity của nhóm từ Sprint trước để “ép tiến độ”, nếu chưa tính kĩ đến các yếu tố khác như focus factor, sự biến động về nhóm, sự thay đổi về công nghệ v.v.

5. Focus Factor là gì?

• Focus factor là tỉ lệ thời gian sản xuất thực tế của nhóm dành cho các story (sau khi trừ đi các thời gian họp hành, học tập, giải lao, ốm đau v.v.).

  • Ví dụ: một ngày làm việc 8 tiếng, có 15 phút họp chính thức, 45 phút thảo luận về design, 30 phút đọc sách kỹ thuật, 30 phút trao đổi về các yêu cầu, 30 phút commit code lên repository, 30 phút viết log dự án; thời gian còn lại là làm việc trên các story (design, test, code) thì hệ số tập trung có thể là:

FF = 1.0 - (15+45+30+30+30+30)/8*60 = 62.5 %.

• Một nhóm chưa thực sự chín chắn, càng ít kinh nghiệm (nhóm mới hoặc va phải công nghệ lạ lẫm v.v.) thì hệ số tập trung càng thấp. Cần xác định được hệ số tập trung thì mới biết được capacity thực tế của nhóm từ đó ước tính được tốc độ thực tế của nhóm. Nhiều người chỉ đặt FF ở mức 50% ngay cả khi nhóm đã tương đối có kinh nghiệm. Theo quan sát của riêng cá nhân tôi, các nhóm ở Hà Nội thường phải chịu một FF lớn là khoảng 7/8 =87.5% (ngày làm việc 8 tiếng thì chịu sức ép sản xuất 7 tiếng; đây có thể là nguyên nhân dẫn đến tình trạng overtime phổ biến hiện nay).

III. Các bước tính chi phí

• Công thức để tính chi phí như sau:

Chi phí = REP/PM/FF

Thời gian phát hành = REP/EV (số Sprint)

• Trong đó:

• REP: Release Estimated Points = Số point ước tính của release • PM: Point – Man = quy đổi 1 point tương ứng man-day • EV: Estimated Velocity = Tốc độ ước tính • FF: Focus Factor = Hệ số tập trung

• Một quy trình ước tính chi phí cơ bản sẽ trải qua các bước sau đây:

  • Xác định focus factor > Xác định estimated velocity > Xác định độ quan trọng và cam kết release> Ước tính chi phí

• Các chi tiết của từng bước được thảo luận kĩ hơn ở bên dưới:

1. Xác định focus factor

• Dựa vào dữ liệu thực tế (nếu nhóm đã có sự cộng tác trước đó), tính chất của dự án, năng lực hiện có của nhóm và các tham số khác để xác định focus factor. Nếu có ít thông tin, có thể lựa chọn con số an toàn là 50%, sau đó làm mịn lại ở Sprint tiếp theo.

• Số liệu FF sẽ ảnh hưởng đến capacity như thế nào?

  • Giả sử FF = 50%. Nhóm bạn có tổng cộng 9 developer, làm việc 5 ngày/1 tuần, Sprint 2 tuần. Vậy là bạn có 9x5x2 = 90 man-day. Nhưng FF=50% nên chỉ dùng có 45 man-day cho sản xuất, còn lại là các việc hành chính, học tập, giải trí v.v. Capacity thực sự để tính tốc độ là 45 man-day.

2. Xác định estimated velocity (EV)

• Có một số tình huống cho việc ước tính velocity như sau:

  • Tình huống 1: Dự án đã chạy được một số Sprint (qua quá trình pilot, hoặc chạy thật):

  Chỉ cần đếm và đo tốc độ trung bình. Các dự án inhouse, RnD có thể rơi vào tình huống này.

  • Tình huống 2: Dự án mới, cần ước tính velocity (để tính được chi phí)

  Cách 1: chạy pilot (hoặc calibration – tùy cách bạn gọi) một Sprint hoặc mini-Sprint (độ dài rút ngắn xuống 1 tuần hoặc ít hơn) để có dữ liệu. Cách này luôn luôn thực hiện được. Dữ liệu empirical luôn là dữ liệu thật nhất. Dĩ nhiên là bạn phải phân tích kĩ các dữ liệu đo đếm được trước khi ra quyết định cuối cùng (Count>Calculate>Judge).

  Cách 2: phân tích dữ liệu lịch sử. Nếu dự án mới không quá khác so với các dự án trước đó, bạn có thể lấy dữ liệu cũ để dùng cho dữ liệu mới. Nếu dự án mới tinh, nhóm mới tinh, bạn không thể dùng được cách này.

• Giả sử trước đó bạn không dùng story point để ước lượng, bạn sẽ phải quy đổi từ đơn vị cũ sang đơn vị mới. Ví dụ, trước đó chức năng “Login” được thực hiện với 5 man-day, giờ đây bạn xác định story “Login” là 1 point thì có quy đổi 1 point = 5 man-day. Nếu bạn chuyển từ waterfall sang agile, bạn có thể thực hiện quá trình calibration để biết được giá trị quy đổi thực sự. Cách làm là: chạy một mini-Sprint để pilot, đo và quy đổi (cách 1).

• Còn nếu trước đó bạn đã dùng point để đo thì không có gì để bàn.

3. Xác định độ quan trọng và xác định cam kết

• Tới đây bạn đã có: FF, Capacity, EV, quy đổi Point-Man_day (PM). Cần phải xác định thêm tổng Story point cần burn để có được ước tính man-day cho một release.

• Làm theo cách của Scrum: Dựa theo tầm quan trọng của story, nhóm Scrum (PO, SM, DevTeam) quyết định trong release tới có bao nhiêu story. Cộng gộp các story point tương ứng với mỗi Story lại sẽ có độ lớn của dự án (tính tới release đó). Gọi giá trị này là REP (release-estimated-point).

4. Ước tính chi phí (theo man-day) và thời gian phát hành

Chi phí = REP/PM/FF

Thời gian phát hành = REP/EV (số Sprint)

• Ví dụ: Nhóm 9 người với FF là 50%, tốc độ ước tính là 50 point/Sprint_2_tuần, quy đổi PM=5 (tức 1 point tương ứng 5 man-day), release 1.0 tới cần 20 story với tổng cộng 200 point (REP = 500) thì:

Chi phí = 500/5/0.5 = 200 man-day.

Thời gian = 500/50 = 10 Sprint = 5 tháng.

• Vậy là theo ước tính này, dự án sẽ cán đích release 1.0 sau 5 tháng với chi phí là 200 man-day.

• Nếu bạn chi cho mỗi 1 man-day là 50/ngày công (bao gồm mọi chi phí tiền lương, máy móc, phụ cấp v.v.) thì chi phí ước tính cho dự án là 200*25 = 5000.

IV. Tổng kết

• Căn cứ vào các tiêu chí khác nhau (thị trường, khách hàng, cơ hội đầu tư v.v.) bạn có thể quyết định sẽ rót vốn vào dự án hoặc làm hợp đồng, v.v.

• Nên nhớ mọi cách tính toán đều mang tính tương đối và chỉ chính xác về con số, trong thực tế sẽ có ít nhiều các yếu tố ảnh hưởng đến việc dự tính và lập kế hoạch cho dự án của bạn. Chính vì vậy, dựa theo cách tính này kết hợp với các yếu tố gây trở ngại cho việc thực hiện kế hoạch của bạn mà điều chỉnh sao cho phù hợp nhất.

• Nếu các bạn có cách làm khác tốt hơn hoặc có đóng góp gì cho bài viết xin vui lòng để lại comment bên dưới. Chân thành cảm ơn!