Hướng dẫn Scrum - 2013

Scrum là một trong những khung thao tác (framework) để phát triển chắc chắn các thành phầm phức hợp. Đây là tài liệu ngắn gọn và khá đầy đủ nhất chứa đựng định nghĩa về Scrum, mô...

Bạn đang xem: Man day là gì

Bạn sẽ xem: Từ: man day là gì, nghĩa của từ manday là gì


*

HoRenSo - để liên tưởng nhóm kết quả

Các nhóm cộng tác đạt được kết quả tốt nhất thông qua tương tác (interaction) chứ không hẳn từ quy trình và công cụ. Dù các bước và công...
*

Triết lý của Scrum là gì?

Scrum được xây dựng dựa vào lý thuyết làm chủ tiến trình thực nghiệm , tuyệt “thực nghiệm luận”(empiricism, hay “duy nghiệm”). Triết lý này chỉ ra rằng rằng học thức đến... Ước tính túi tiền và độ to cho dự án công trình theo giải pháp của Scrum

Warning: đầy đủ ai vướng phải việc fixed-price, fixed-cost, fixed-date có thể sẽ không kiếm kiếm được giải mã trong vấn đề “ước tính đưa ra phí” trong bài viết này. Bài bác này chỉ ra phương thức tính toán ngân sách theo phương pháp của Scrum với trả định bạn đã có sẵn một Scrum Team, hoàn toàn có thể không tương hợp với phương pháp làm của doanh nghiệp hiện nay.

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

Dẫn nhập

Scrum được minh chứng bằng thực tiễn sinh động là công dụng và thú vị. Tuy vậy, sách viết về Scrum không nhiều đề cập đến những chi tiết liên quan mang đến tiền nong, vốn là phần nhiều thứ “không đùa với khách hàng thơ”. Nên câu hỏi “làm sao để xác minh giá trị hòa hợp đồng?”, “làm sao nhằm tính được túi tiền cho dự án?” luôn là những thắc mắc đâu đầu nhà quản lí dự án.

Nhiều người cho rằng ước tính (Nam) tuyệt lập chiến lược (Kniberg) là những năng lực khó khăn tốt nhất trong thực tiễn làm dự án công trình phần mềm. Các phương án kĩ thuật đã được giới thiệu và áp dụng thoáng rộng như Function Points, Cocomo, …. Tuy vậy, các cách thức này có phần “không tương thích” với cách làm agile (Cohn). Mike Cohn ra mắt một lựa chọn khác cho người làm theo triết lí Agile, call 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, cân xứng với Agile (Sutherland, Kniberg).

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

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

User Story là gì?

User Story là một phiên bản tóm tắt yêu cầu người dùng. Thông thường, user story vị khách hàng, hoặc thay mặt của khách hàng hàng, bạn thực sự hiểu nghiệp vụ và nắm bắt được chính xác yêu cầu của bản thân mình đối với nhóm phát triển. Story không đối chọi thuần là giải pháp requirement (Cohn), mà còn là công ráng để giao tiếp, chất kết dính và dòng “phanh hãm” trong vạc triển. Scrum điều khoản Product Owner sở hữu những story (thông qua sản phẩm backlog), dẫu vậy đó không phải quá trình đơn thuần của hàng hóa Owner ( lấy ví dụ như như tại 1 vài bí quyết làm khác, “BA làm cho requirement” v.v.).

User Story Point là gì?

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

Agile Estimation là gì?

Là phương pháp ước lượng độ béo của story theo cách linh hoạt. áp dụng Scrum Poker, đội sẽ review các story dựa vào sự so sánh với những story mẫu (là những story dễ dàng hiểu so với nhóm, gán giá trị mở màn để có tác dụng “mốc” review cho những story khác).

Trước khi Sprint 1 diễn ra, nhóm Scrum hợp tác trong cuộc họp Kế hoạch xuất bản (Release Planning) để khẳng định những tài năng nào sẽ có được trong phiên bản phát hành, thời điểm nào sẽ thi công sản phẩm. Lúc đó nhóm sẽ cần ước tính cho toàn bộ các story được xác định tham gia vào release tới.

Velocity là gì?

Là vận tốc burn được từng nào điểm (point) vào một Sprint. Lấy một 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ử gần như thứ ko đổi, một release được mong tính lúc đầu có độ mập 480 point thì nhóm nên trải qua khoảng tầm 480/48 = 10 Sprint.

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

Focus factor là gì?

Ví dụ một ngày thao tác 8 tiếng, tất cả 15 phút họp thiết yếu thức, 45 phút trao đổi về design, 1/2 tiếng đọc sách kĩ thuật, nửa tiếng trao thay đổi về những yêu cầu, khoảng 30 phút commit code lên repository, trong vòng 30 phút viết log dự án; thời hạn còn lại là thao tác làm việc trên những story (design, test, code) thì thông số tập trung rất có thể là:

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

Một đội càng không nhiều mature (nhóm mới, team “ô hợp”, hoặc va phải technology lạ lẫm v.v.) thì hệ số tập trung càng thấp. Cần khẳng định được hệ số triệu tập thì mới biết được capacity thực tế của group từ đó mong tính được tốc độ thực tế của nhóm. Không ít người chỉ đặt FF sinh sống mức một nửa (Kniberg) ngay cả khi team đã kha khá mature. Theo quan liền kề của riêng cá thể tôi (không có dữ liệu đầy đủ), các nhóm ở thủ đô thường nên chịu một ff béo là khoảng chừng 7/8 =87.5% (ngày thao tác 8 giờ đồng hồ thì chịu đựng sức ép thêm vào 7 tiếng; đây hoàn toàn có thể là tại sao dẫn mang lại tình trạng overtime phổ cập hiện nay).

Các cách tính bỏ ra phí

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

Chi mức giá = REP /PM/FF

Thời gian xuất bản = REP /EV (số Sprint)

Trong đó:

REP: Release Estimated Points = Số point mong tính của releasePM: Point – Man = quy đổi 1 point tương ứng man-dayEV: Estimated Velocity = tốc độ ước tính FF: Focus Factor = hệ số tập trung

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

Xác định focus factor > xác định estimated velocity > xác minh độ đặc biệt và cam đoan release> Ước tính ngân sách chi tiêu

Các chi tiết của mỗi bước được bàn bạc kĩ rộng ở bên dưới.

Xác định focus factor

Dựa vào dữ liệu thực tế (nếu team đã tất cả sự hiệp tác trước đó), đặc thù của dự án, năng lượng hiện có của tập thể nhóm và các tham số khác để xác minh focus factor. Nếu gồm ít thông tin, rất có thể lựa chọn con số an ninh là 50%, tiếp đến làm mịn lại nghỉ ngơi Sprint tiếp theo.

Số liệu FF sẽ tác động đến capacity như vậy nào?

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

 

Xác định estimated velocity (EV)

Có một vài tình huống cho vấn đề ước tính velocity như sau:

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

Chỉ đề nghị đếm với đo tốc độ trung bình. Những dự án inhouse, RnD hoàn toàn có thể rơi vào trường hợp này. Dễ.

Tình huống 2: dự án mới, cần ước tính velocity (để tính được bỏ ra phí)

Cách 1: chạy pilot (hoặc calibration – tùy cách chúng ta gọi) một Sprint hoặc mini-Sprint (độ dài tinh giảm xuống 1 tuần hoặc không nhiều hơn) để có dữ liệu. Phương pháp này luôn luôn luôn tiến hành được. Dữ liệu empirical luôn luôn là tài liệu thật nhất. đương nhiên là chúng ta phải so sánh kĩ những dữ liệu thống kê được trước lúc ra quyết định sau cùng (Count>Calculate>Judge).

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

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

Còn giả dụ trước đó các bạn đã dùng point nhằm đo thì không có gì nhằm bạn, biết rồi!

 

Xác định độ đặc trưng và xác minh cam kết

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

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

Ước tính giá cả (theo man-day) và thời hạn phát hành

 

Chi mức giá = REP /PM/FF

Thời gian desgin = REP /EV (số Sprint)

 

Ví dụ: team 9 fan với FF là 50%, vận tốc ước tính là 50 point/Sprint_2_tuần, quy đổi PM=5 (tức 1 point tương xứng 5 man-day), release 1.0 cho tới cần đôi mươi story với tổng số 200 point (REP = 500) thì:

Chi giá tiền = 500/5/0.5 = 200 man-day.

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

Xem thêm: Công Văn Số 5555/Bgdđt-Gdtrh Ngày 08/10/2014, Công Văn 5555/Bgdđt

 

Vậy là theo cầu 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 chúng ta chi cho từng 1 man-day là 50$/ngày công (bao gồm mọi chi phí tiền lương, lắp thêm móc, phụ cấp cho v.v.) thì chi tiêu ước tính cho dự án công trình là 200*25 = 5000$.

Thay lời kết

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

Không biết cách đo lường này bao gồm hữu ích với các bạn không? Nếu có cách làm khác giỏi hơn, xin vui mừng khai sáng tôi ;-)

Tham khảo

Mike Cohn, User stories applied: for agile software development.Mike Cohn, Agile Estimation and PlanningSteve McConnell, Software Estimation: Demystifying the black Art

D