Ước Tính Chi Phí Và độ Lớn Cho Dự án Theo Cách Của Scrum

Warning: những ai vướng phải bài toán fixed-price, fixed-cost, fixed-date có thể sẽ không tìm kiếm được lời giải trong bài toán “ước tính chi phí” trong bài viết này. Bài 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ó thể không tương thích với cách làm của bạn hiện nay.

Xin bạn kiên nhẫn đọc hết bài này, nếu có ý kiến đóng góp hoặc phản biện, xin hãy khai sáng tôi ;-)

Dẫn nhập

Scrum được chứng minh bằng thực tiễn sinh động là hiệu quả và thú vị. 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ứ “không đùa với khách thơ”. 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 đâu đầu nhà quản lí dự án.

Nhiều người cho rằng ước tính (Nam) hay lập kế hoạch (Kniberg) 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 (Cohn). Mike Cohn 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 (Sutherland, Kniberg).

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 (Mc Connell).  Sự chuyển dịch sang agile trong thời gian hơn một thập kỉ qua (FR,) đồ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 (Mc Connell) 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.

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

User Story là gì?

User Story là một bản tóm tắt nhu cầu 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, 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. Story không đơn thuần là công cụ requirement (Cohn), mà còn là công cụ để giao tiếp, chất kết dính và 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.).

Xem thêm tại đây: http://goo.gl/unAii

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.

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.

Xem thêm ở đây: http://goo.gl/zvxkN; xem thêm cách chơi bài (animated) trong http://goo.gl/imDNC .

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) = 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.

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 càng ít mature (nhóm mới, nhóm “ô hợp”, 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% (Kniberg) ngay cả khi nhóm đã tương đối mature. Theo quan sát của riêng cá nhân tôi (không có dữ liệu đầy đủ), 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).

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.

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.

 

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. Dễ.

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, biết rồi!

 

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

Ướ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$.

Thay lời kết

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

Không biết cách tính toán này có hữu ích với bạn không? Nếu có cách làm khác tốt hơn, xin vui lòng khai sáng tôi ;-)

Tham khảo

1. Hendrik Kniberg, Scrum and XP from the trenches (http://www.infoq.com/minibooks/scrum-xp-from-the-trenches)
2. Jeff Sutherland, Tại sao point lại tốt hơn giờ (http://hanoiscrum.net/hnscrum/blogs1/109-story-points)
3. Mike Cohn, User stories applied: for agile software development.
4. Mike Cohn, Agile Estimation and Planning
5. Steve McConnell, Software Estimation: Demystifying the Black Art
6. Nam (Nguyễn Thành), Talkshow tại Viettel (http://www.youtube.com/playlist?list=PLAA470876AC3C5DB9).

D

 Dương Trọng Tấn