ƯỚC LƯỢNG CHI PHÍ

PHÁT TRIỂN PHẦN MỀM

NGUYỄN CHÂU LONG - CH1802052

BÙI TỔNG NHA - CH1801033
• Ước lượng chi phí phát triển phần mềm là quá trình dự đoán chi phí
cần thiết để hoàn thành một dự án phần mềm.
• Kết quả của quá trình ước lượng là số nhân lực, kinh phí, lịch biểu và
tài nguyên cần sử dụng.
• Mục đích thực hiện ước lượng:
 Lập kế hoạch và ngân sách.
 Phân tích rủi ro và quản lý dự án.

2
ƯỚC LƯỢNG CHI PHÍ PHẦN MỀM
THEO DỰ ÁN AGILE

3
 USER STORY
• User Story là một tài liệu sơ giản về yêu cầu sản phẩm với góc nhìn
người dùng. Thông thường, User Story do khách hàng, hoặc đại điện
của khách hàng viết, tuy nhiên nếu có sự cộng tác của Developer thì
nhóm và khách hàng sẽ có sự chia sẻ hiểu biết về sản phẩm tốt hơn.
• Với những nhóm dùng bảng vật lý thì User Story được viết trên các
thẻ nhỏ hoặc trên các miếng giấy dán. Nhóm có thể dán các thẻ này
lên bảng như những hạng mục của Product Backlog.

4
 USER STORY (tt)
User story nên theo mô hình 3C:
• Card (Thẻ): Thông thường, User Story được viết trên một thẻ nhỏ. Điều đó có
nghĩa là nó thường ngắn để có thể viết trên một thẻ. Nếu bạn có viết trên một hệ
thống khác như Trello, Jira, Assembla hoặc Redmine cũng nên giữ nó ngắn.
• Conversation (Trao đổi): Story là những câu truyện giữa khách hàng và nhóm
phát triển. Do đó chi tiết của User Story được làm rõ thông qua các cuộc trao đổi
(nên là trực tiếp) với khách hàng. Nội dung của User Story sẽ ngày càng cụ thể tuy
thuộc vào độ ưu tiên của nó (nếu ưu tiên cao, cần làm sớm thì sẽ có nọi dung chi
tiết, nếu ưu tiên thấp thì chỉ chứa nội dung chung).
• Confirmation (Xác nhận): User Story có tiêu chí chấp nhận (Acceptance Criteria)
để khách hàng suy nghĩ cụ thể về yêu cầu và Nhóm Phát triển có thể hiểu yêu cầu
rõ hơn và xác nhận được khi nào sản phẩm hoàn thành. 5
 USER STORY (tt)
User story cũng nên tuân theo các tiêu chí INVEST:
• Independent (Độc lập): Độc lập với các User Story khác. Giúp Product Owner tự
do thay đổi thứ tự trong Product Backlog và nhóm phát triển dễ dàng phát triển.
• Negotiable (Thương lượng): Đàm phán giúp cho nhóm phát triển và Product
Owner cùng nhau xây dựng nội dung phụ hợp cho những thay đổi trong tương lai.
• Valuable (Có giá trị): User Story phải có giá trị với khác hàng. Người kỹ thuật thấy
khung làm việc, cơ sở dữ liệu, thiết kế là quan trọng. Đối với khách hàng thì không.
• Estimable (Ước lượng): User Story tốt có thể ước lượng gần chính. Khả năng ước
tính được giúp nhóm ước lượng tốt hơn công việc sẽ làm và cả kế hoạch phát hành.
• Testable (Kiểm thử): Các mô hình phát triển BDD hoặc ATDD có giá trị vì yêu cầu
có thể kiểm thử khi User Story hoàn thành. 6
 USER STORY POINT LÀ GÌ?
• Đại lượng chỉ độ lớn của các user story trong một dự án. Trong mỗi Sprint,
nhóm sẽ dùng Planning Poker để đánh giá độ lớn nhỏ của các user story này và
ghi các giá trị đó lên mỗi user story card.
• VD: toàn dự án có 3 user story: Đăng nhập, Giỏ hàng, Hủy đơn hàng:
• Đăng nhập: được gán 3 story point.
• Giỏ hàng: được gán 8 story point.
• Hủy đơn hàng: được gán 5 story point.
 Toàn bộ dự án là 16 story point.
7
 STORY POINT LÀ ĐƠN VỊ CỐ ĐỊNH
• Không có chuyện một point ở Sprint 2 thì được tính ½ point ở Sprint 1. Chỉ có
việc “Hủy đơn hàng” ở Sprint 2 có thể được ước lượng lại là 8 story points.
• Tất cả các point đều phải quy chiếu về một cái gì đó làm mẫu.
• Ví dụ: lúc đầu các user story đều được mang ra so sánh với “Đăng nhập”. Thì
đến Sprint 3, các user story khác cũng phải so sánh với “Đăng nhập”. Nếu không
thì khái niệm story point không có giá trị.

8
 ƯỚC TÍNH LINH HOẠT
(AGILE ESTIMATION)
• Ướ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.
• Trước khi Sprint 1 diễn ra, nhóm họp để 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.

9
 ƯỚC TÍNH LINH HOẠT
(AGILE ESTIMATION)
• Ví dụ: Dự án phát triển website có các hạng mục sau phải hoàn thành là: đăng
nhập, đăng ký và lấy lại mật khẩu.
• Tính năng đăng nhập nhỏ và rõ ràng, nên cho tính năng đăng nhập 1 điểm.
• Tính năng đăng ký cần công sức gấp 3 lần tính năng đăng nhập, nên cho tính
năng đăng ký 3 điểm.
• Tính năng lấy lại mật khẩu tốn nhiều công sức hơn đăng nhập (1 điểm), nhưng ít
hơn đăng ký (3 điểm), nhóm cho tính năng lấy lại mật khẩu 2 điểm.

10
 ƯỚC TÍNH LINH HOẠT BẰNG
PLANNING POKER
• Bước 1: User Story được thông báo cho toàn bộ nhóm,
mỗi thành viên trong nhóm ước tính số điểm Story Points
và không tiết lộ lựa chọn của mình cho người khác.
• Bước 2: Tất cả các ước tính được công bố cùng một lúc.
• Bước 3: Ước tính cao và thấp được giải thích bởi những người chọn và sau đó sẽ
được đưa ra thảo luận.
• Sau một hồi thảo luận, mỗi thành viên chọn một lá bài để ước tính lại và các lá bài
của họ lại đồng thời được lật lên. Quy trình này sẽ lặp đi lặp lại cho tới khi đạt
được sự đồng thuận của các thành viên.
11
 ƯỚC TÍNH LINH HOẠT VỚI
PLANNING POKER
• Một yếu tố quan trọng khác của Planning Poker là các giá trị cho phép của các ước
tính chỉ có thể là một số trong số dãy Fibonacci: 1, 2, 3, 5, 8. Điều này hạn chế
việc phán đoán giá trị chính xác khó khăn hơn khi mọi thứ trở nên lớn hơn.
• Quá trình này bỏ qua một yếu tố quan trọng. Khi nhóm nghiên cứu ước tính User
Story đầu tiên, mỗi thành viên trong nhóm làm thế nào để biết điều gì tạo thành
một Story Point? Không có point tham khảo để họ so sánh.

12
 ƯỚC TÍNH HAI GIAI ĐOẠN
• Phương pháp ước tính này tránh được vấn đề không có point tham khảo bằng
cách bắt đầu quá trình với User Story thứ hai
• Không phải là User Story đầu tiên, do đó có thể so sánh ngay lập tức.
• Phương pháp này có hai giai đoạn:

13
 ƯỚC TÍNH HAI GIAI ĐOẠN
• Giai đoạn đầu tiên:

14
 ƯỚC TÍNH HAI GIAI ĐOẠN
• Thành viên đầu tiên của nhóm đặt user story của họ tại vị trí.
• Ở bên trái của user story đầu tiên, mục đích thể hiện nó đòi hỏi ít công việc hơn
là user story đầu tiên.
• Ở bên phải, chỉ ra rằng nó đòi hỏi nhiều công việc hơn.
• Bên dưới một user story khác, chỉ ra rằng nó đòi hỏi cùng một lượng công việc.
• Mỗi thành viên trong nhóm thay phiên nhau đặt một user story mới xung quanh
những user story mà người khác đã đặt.
• Họ có thể di chuyển một user story được đặt trước đó đến một vị trí khác nếu họ
không đồng ý với vị trí ban đầu. - Tiếp tục chơi cho đến khi hết user story và
không ai muốn sắp xếp lại thứ tự nữa.
15
 ƯỚC TÍNH HAI GIAI ĐOẠN
• Giai đoạn hai:

16
 ƯỚC TÍNH HAI GIAI ĐOẠN
• Cũng đòi hỏi một chuỗi Fibonacci, hoặc một cái gì đó tương tự.
• Số 1 được đặt phía trên cột câu chuyện ngoài cùng bên trái, đại diện cho user
story nhỏ nhất.
• Thành viên nhóm đầu tiên lấy số tiếp theo: 2 và đặt nó lên trên những user story
anh / cô ấy đánh giá là gấp đôi công việc của cột đầu tiên.
• Người chơi tiếp theo nhận số tiếp theo và gán nó vào một cột user story tương
tự.
• Mỗi người chơi có một tùy chọn khác nhau, để thay thế số trước đó bằng số của
họ, ví dụ: họ có thể cảm thấy rằng những user story được đánh số 5 có thể trong
thực tế là 8
17
 ƯỚC TÍNH HAI GIAI ĐOẠN
• Trong cả hai lượt chơi, giá trị 0 cũng có thể được sử dụng trong trường hợp các
user story nhỏ nhất thực sự được coi là nhiệm vụ 30 phút và có thể được gộp vào
những công việc khác với chi phí ít hoặc không có chi phí.
• Lưu ý rằng chỉ có một số lượng giới hạn các user story bằng 0 được miễn phí.
• Các phương pháp ước tính này có thể được sử dụng trước khi một dự án được
xoay vòng và khi user story mới được xác định hoặc những user story hiện có
thay đổi.

18
 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…
• Ví dụ, Sprint 1 nhóm burn được 48 point, Sprint 2 được 49, Sprint 3 được 53 thì
V = (48+49+53)/3 = 50.
• Giả sử mọi thứ không đổi, ước tính ban đầu có độ lớn 500 point thì phải cần có
500/50 = 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ì. 19
 VELOCITY (TỐC ĐỘ) LÀ GÌ?
• Velocity là thước đo số điểm mà một đội có thể thực hiện trong một lần lặp dựa
trên hiệu suất trước đó. Điều quan trọng là các story points và Velocity vẫn còn
trừu tượng để tránh rơi vào thói quen cũ là ước lượng tuyệt đối dựa trên thời
gian. Bằng suy luận, Velocity sẽ gán một giá trị thời gian tuyệt đối cho một story
points theo cách sau:
• Số người làm của nhóm cho mỗi story points = (số ngày có sẵn cho toàn bộ nhóm trong một
lần lặp lại-các nhiệm vụ ( như kỳ nghỉ, cuộc họp, v.v.))/ Velocity.
• Ví dụ: Một nhóm gồm 5 người có 50 ngày làm việc nhóm cho sprint 2 tuần. 1 người thì
trung bình 1 tuần mất 1 ngày cho mấy việc linh tinh như meeting, nghỉ ngơi, và các vấn đề
khác. vậy cả khâu 2 tuần mỗi người sẽ mất 2 ngày không làm việc. Velocity của nhóm cố
định là 46,5. Vậy số người thực tế cần dùng là: 50 - (5 x 2) / 46,5 = 0,86

20
 VELOCITY (TỐC ĐỘ) LÀ GÌ?
• Điều quan trọng là nhận ra rằng giá trị 'ngày làm việc của team cho 1 story point'
là trung bình của tất cả các thành viên trong nhóm và tất cả các thành viên trong
nhóm đều phải tham gia vào vòng lặp thì Velocity mới có ý nghĩa. Nếu 3 lập
trình viên có kinh nghiệm được thay thế bằng các thành viên mới trong một
sprint thì Velocity cho sprint đó phải được đánh giá lại.
• Mặc dù ước tính thời gian story point có thể dễ dàng nhưng nó lại không dễ làm.

21
 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…).
• VD: 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 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.
22
 CÁC BƯỚC TÍNH CHI PHÍ
• 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ông thức tính chi phí:
Chi phí = REP/PM/FF Số Sprint = REP/EV
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. 23
 XÁC ĐỊNH FOCUS FACTOR
• Dựa vào dữ liệu thực tế 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 đó điều chỉnh 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 có tổng cộng 9 developer, làm việc 5 ngày/1 tuần,
Sprint 2 tuần. Vậy 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.

24
 XÁC ĐỊNH
ESTIMATE VELOCITY (EV)
• 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òn nếu trước đó bạn đã dùng point để đo thì không có gì để bàn.

25
 XÁC ĐỊNH ĐỘ QUAN TRỌNG
• 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 sẽ 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).

26
 ƯỚC TÍNH CHI PHÍ
(THEO MAN-DAY)
• 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. Mỗi Sprint 2 tuần  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à 80$/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*80 = 1600$
27
 KẾT LUẬN
• 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.

28