MAN DAY LÀ GÌ

      27

Hướng dẫn Scrum - 2013

Scrum là một trong những form thao tác làm việc (framework) nhằm cách tân và phát triển bền chắc những sản phẩm phức hợp. Đây là tư liệu nlắp gọn và đầy đủ tuyệt nhất chứa đựng tư tưởng về Scrum, tế bào...

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


*

HoRenSo - để thúc đẩy team tác dụng

Các team hợp tác đạt được công dụng cực tốt trải qua xúc tiến (interaction) chứ đọng chưa phải từ quá trình cùng mức sử dụng. Dù tiến trình với công...
*

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

Scrum được phát hành dựa trên triết lý thống trị các bước thực nghiệm , tốt “thực nghiệm luận”(empiricism, xuất xắc “duy nghiệm”). Lý thuyết này chỉ ra rằng tri thức mang đến...
Ước tính ngân sách với độ Khủng đến dự án công trình theo cách của Scrum

Warning: gần như ai vướng bắt buộc bài xích tân oán fixed-price, fixed-cost, fixed-date có thể đã không tìm kiếm tìm được giải thuật trong bài xích toán thù “dự trù chi phí” trong nội dung bài viết này. Bài này chỉ ra phương pháp tính toán ngân sách Theo phong cách của Scrum cùng với mang định bạn đã có sẵn một Scrum Team, có thể không cân xứng với giải pháp có tác dụng của chúng ta bây chừ.

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

Dẫn nhập

Scrum được minh chứng bởi thực tế sinh động là tác dụng với thú vui. Tuy vậy, sách viết về Scrum không nhiều đề cập đến rất nhiều chi tiết liên quan mang lại chi phí nống, vốn là phần nhiều đồ vật “không nghịch cùng với khách thơ”. Nên câu hỏi “làm thế nào để khẳng định quý hiếm hòa hợp đồng?”, “làm thế nào để tính được ngân sách cho dự án?” luôn luôn là phần đông câu hỏi đâu đầu nhà quản ngại lí dự án.

phần lớn fan nhận định rằng ước tính (Nam) giỏi lập kế hoạch (Kniberg) là hồ hết tài năng trở ngại độc nhất trong thực tế làm cho dự án công trình ứng dụng. hầu hết phương pháp kĩ thuật đã được giới thiệu với áp dụng thoáng rộng nhỏng Function Points, Cocomo, …. Tuy vậy, những cách thức này còn có phần “ko tương thích” cùng với giải pháp làm cho agile (Cohn). Mike Cohn trình làng một chắt lọc không giống cho tất cả những người làm theo triết lí Agile, hotline là agile estimation với đơn vị đo là story point. Những tín đồ làm agile gần như reviews đó là thước đo khả dụng, cân xứng cùng với Agile (Sutherland, Kniberg).

Một cách thức ước chừng giỏi Khi được sử dụng đúng vị trí. Các tmê mệt số chính ảnh hưởng đến sự chọn lựa phương thức ước chừng bao gồm kích thước dự án công trình (mập, vừa phải, nhỏ) cùng phương thức luận cải tiến và phát triển ứng dụng (Mc Connell). Sự chuyển dịch lịch sự agile vào thời gian rộng một thập kỉ qua (FR,) đồng nghĩa tương quan với việc các phương thức ước tính bottom-up (nlỗi agile estimation chẳng hạn) được yêu mến rộng (Mc Connell) nhờ vào độ chính xác cao dựa vào tài liệu thực nghiệm của bao gồm dự án.

Nhắc lại những định nghĩa cơ bản

User Story là gì?

User Story là một bản tóm tắt nhu yếu người tiêu dùng. Thông thường, user story vị quý khách hàng, hoặc thay mặt của công ty, bạn đích thực gọi nhiệm vụ cùng thâu tóm được đúng mực yên cầu của mình so với team trở nên tân tiến. Story không đối kháng thuần là lao lý requirement (Cohn), cơ mà còn là một hình thức để tiếp xúc, chất kết nối và cái “pkhô nóng hãm” vào cải tiến và phát triển. Scrum qui định Product Owner cài đặt các story (trải qua hàng hóa backlog), nhưng mà đó không hẳn các bước 1-1 thuần của Product Owner ( ví như tại 1 vài ba phương pháp làm khác, “BA có tác dụng  requirement” v.v.).

User Story Point là gì?

Đó là đại lượng chỉ độ mập kha khá của các user story vào và một dự án. Trong một phiên hoạch định trước Sprint, team cải cách và phát triển cần sử dụng Scrum Poker để Reviews độ bự bé bỏng các story này, với ghi những giá trị đó lên từng user story card.

Agile Estimation là gì?

Là cách thức ước tính độ lớn của story Theo phong cách linch hoạt. Sử dụng Scrum Poker, nhóm vẫn nhận xét các story dựa theo sự đối chiếu cùng với những story chủng loại (là những story dễ hiểu đối với team, gán giá trị khởi đầu để gia công “mốc” Review cho những story khác).

Trước khi Sprint 1 ra mắt, Nhóm Scrum cộng tác vào cuộc họp Kế hoạch Phát hành (Release Planning) để xác định số đông chức năng như thế nào sẽ có được vào phiên bản xây dựng, thời điểm như thế nào sẽ tạo sản phẩm. khi kia đội đang đề xuất ước tính mang đến tất cả những story được xác minh tsi mê gia vào release cho tới.

Velothành phố là gì?

Là tốc độ burn được bao nhiêu điểm (point) trong một Sprint. ví dụ như Sprint 1 team burn được 45 point, Sprint 2 được 51, Sprint 3 được 48 thì tốc độ vừa đủ được tính:

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

Giả sử phần đông thiết bị không đổi, một release được ước tính thuở đầu có độ béo 480 point thì đội bắt buộc trải qua khoảng tầm 480/48 = 10 Sprint.

Lưu ý: velocity chỉ có giá trị tương đối, hỗ trợ bài toán dự tính, quý hiếm tuyệt đối của nó không tồn tại ý nghĩa gì. Cấp cai quản lí về cơ bản bắt buộc căn cứ vào velothành phố của nhóm trường đoản cú Sprint trước để “nghiền tiến độ”, giả dụ không tính kĩ đến những yếu tố khác ví như focus factor, sự dịch chuyển về đội, sự biến hóa về công nghệ v.v.

Focus factor là gì?

Focus factor là tỉ lệ thời gian chế tạo thực tế của nhóm dành cho các story (sau khi trừ đi các thời hạn họp hành, học tập, giải lao, nhỏ nhức v.v.).

Xem thêm: Hot Boy Minh Châu Quyết Tâm Xóa Mác 'Hot Boy Cover', Minh Châu Quyết Tâm Xóa Mác 'Hot Boy Cover'

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

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

Một nhóm càng ít mature (team bắt đầu, đội “ô hợp”, hoặc va bắt buộc technology không quen v.v.) thì thông số tập trung càng tốt. Cần xác minh được thông số triệu tập thì mới biết được capathành phố thực tế của group tự đó ước tính được tốc độ thực tiễn của tập thể nhóm. Nhiều người chỉ đặt FF ở tại mức 50% (Kniberg) trong cả khi team đang kha khá mature. Theo quan gần kề của riêng biệt cá nhân tôi (không tồn tại dữ liệu đầy đủ), các nhóm sinh sống TP Hà Nội thường xuyên đề xuất chịu một ff bự là khoảng tầm 7/8 =87.5% (ngày làm việc 8 giờ đồng hồ thì Chịu đựng mức độ ép cung ứng 7 tiếng; phía trên có thể là nguyên nhân dẫn mang lại triệu chứng overtime thịnh hành hiện nay nay).

Các bdự trù bỏ ra phí

Công thức nhằm tính ngân sách nhỏng sau:

Chi phí = REP /PM/FF

Thời gian xây cất = REP /EV (số Sprint)

Trong đó:

REP: Release Estimated Points = Số point ước 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 tiến trình dự tính ngân sách cơ bản vẫn trải qua các bước sau đây:

Xác định focus factor > Xác định estimated velođô thị > Xác định độ quan trọng đặc biệt cùng cam đoan release> Ước tính chi phí

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

Xác định focus factor

Dựa vào tài liệu thực tiễn (nếu team đang có sự hiệp tác trước đó), đặc thù của dự án, năng lượng hiện có của group cùng các tham số không giống nhằm xác minh focus factor. Nếu bao gồm không nhiều thông tin, có thể chọn lựa số lượng bình yên là 50%, kế tiếp làm cho mịn lại làm việc Sprint tiếp theo sau.

Số liệu FF sẽ ảnh hưởng cho capađô thị như thế nào?

Giả sử FF = một nửa. Nhóm chúng ta bao gồm tổng số 9 developer, thao tác làm việc 5 ngày/một tuần lễ, Sprint 2 tuần. Vậy là các bạn bao gồm 9x5x2 = 90 man-day. Nhưng FF=một nửa nên có thể dùng bao gồm 45 man-day mang đến tiếp tế, sót lại là các việc hành chủ yếu, tiếp thu kiến thức, vui chơi giải trí v.v. Capathành phố 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 Việc dự trù velođô thị như sau:

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

Chỉ cần đếm và đo tốc độ mức độ vừa phải. Các dự án inhouse, RnD có thể rơi vào tình thế trường hợp này. Dễ.

Tình huống 2: Dự án bắt đầu, buộc phải dự tính velocity (để tính được bỏ ra phí)

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

Cách 2: đối chiếu tài liệu lịch sử. Nếu dự án công trình bắt đầu không thật khác đối với các dự án công trình trước kia, chúng ta có thể mang dữ liệu cũ nhằm dùng mang lại dữ liệu bắt đầu. Nếu dự án bắt đầu tinch, team bắt đầu tinch, các bạn chẳng thể sử dụng được cách này.

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

Còn giả dụ trước kia bạn đã cần sử dụng point để đo thì không tồn tại gì để các bạn, biết rồi!

 

Xác định độ quan trọng đặc biệt cùng xác minh cam kết

Tới trên đây chúng ta sẽ có: FF, Capacity, EV, quy đổi Point-Man_day (PM). Cần đề nghị xác minh thêm tổng Story point nên burn để có được dự tính man-day cho một release.

Làm theo cách của Scrum: Dựa theo khoảng quan trọng đặc biệt của story, Nhóm Scrum (PO, SM, DevTeam) đưa ra quyết định trong release tới tất cả bao nhiêu story. Cộng gộp những story point tương xứng với mỗi Story lại sẽ sở hữu độ Khủng của dự án công trình (tính cho tới release đó). Điện thoại tư vấn giá trị này là REP (release-estimated-point).

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

 

giá thành = REP /PM/FF

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

 

Ví dụ: Nhóm 9 fan với FF là 1/2, tốc độ ước tính là 50 point/Sprint_2_tuần, quy thay đổi PM=5 (tức 1 point tương ứng 5 man-day), release 1.0 tới đề nghị trăng tròn story cùng với tổng cộng 200 point (REPhường = 500) thì:

Ngân sách chi tiêu = 500/5/0.5 = 200 man-day.

Thời gian = 500/50 = 10 Sprint = 5 mon.

 

Vậy là theo ước tính này, dự án công trình đã cán đích release 1.0 sau 5 tháng cùng với ngân sách là 200 man-day.

 

Nếu chúng ta chi cho mỗi 1 man-day là 50$/ngày công (bao gồm phần đa chi phí chi phí lương, trang thiết bị, prúc cấp v.v.) thì ngân sách dự tính cho dự án công trình là 200*25 = 5000$.

Txuất xắc lời kết

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

Không biết cách tính tân oán này có có ích cùng với các bạn không? Nếu bao gồm biện pháp làm không giống giỏi rộng, xin vui vẻ knhị sáng tôi ;-)

Tđam mê khảo

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

D