Kinh Nghiệm về Cách tính Man_day 2022
Bạn đang tìm kiếm từ khóa Cách tính Man_day được Cập Nhật vào lúc : 2022-02-14 06:20:12 . Với phương châm chia sẻ Thủ Thuật về trong nội dung bài viết một cách Chi Tiết Mới Nhất. Nếu sau khi tìm hiểu thêm nội dung bài viết vẫn ko hiểu thì hoàn toàn có thể lại Comments ở cuối bài để Ad lý giải và hướng dẫn lại nha.
Điểm cốt lõi khi estimate effort (phần 1)
Thứ Tư, 27/03/2019Tram Ho
Mở đầu
Bài viết này sẽ trình làng về kiểu cách estimate effort bỏ ra khi thao tác.
Nội dung chính
- Điểm cốt lõi khi estimate effort (phần 1)Mở đầuEffort là gì?Tại sao nên phải có ý thức về effort?C trong QCDTầm quan trọng của việc estimate effortNhững case không cần estimate effort (?)Cách estimateKhái quátChia nhỏ taskVideo liên quan
Effort là gì?
Effort nghĩa là tổng thời hạn ước tính cho tới lúc hoàn thành xong 1 task nào đó trong việc làm. Nó khác với nghĩa của cụm từ TAT (Turnaround time) xuất hiện trong kỳ thi FE.
Ví dụ, trong trường hợp có một task cần 40 tiếng để hoàn thành xong, vậy hoàn toàn có thể nói rằng effort đó đó là 40 tiếng. Nếu một ngày thao tác 8 tiếng, hoàn toàn có thể hiểu 40 tiếng là 5 man-day. Ngoài ra, nếu một tháng đi làm việc 20 ngày thì 40 tiếng đõ sẽ tương tự 0.25 man-month.
Thông thường man-day và man-month sẽ là cty được sử dụng để tính effort.
Thời học viên hẳn bạn không để ý lắm đến effort nhưng nếu trở thành kỹ sư IT thao tác trong công ty thì nên phải ghi nhận về effort.
Tại sao nên phải có ý thức về effort?
Cần có ý thức về effort là chính bới thời hạn thao tác mà nhân viên cấp dưới hoàn toàn có thể làm là hạn chế.
Theo quy định của Luật lao động, nhân viên cấp dưới thao tác tại một công ty, không phải phía vận hành công ty sẽ có được số lượng giới hạn về thời hạn thao tác tối đa. Năm 2015, do vụ việc làm quá giờ ở một doanh nghiệp lớn, quy định về việc làm thêm giờ trở nên nghiêm ngặt hơn. Người tử vong do thao tác quá sức là vì trong một tháng làm thêm giờ khoảng chừng 80 tiếng.
Ngoài ra, cũng một phần vì yếu tố ngân sách. Thông thường nhân viên cấp dưới văn phòng được trả lương theo giờ thao tác nên dù đảm bảo tiêu chuẩn về luật lao động đi nữa, nếu ngân sách công ty không đủ thì vẫn phải hạn chế làm thêm giờ.
Dưới thời kỳ kinh tế tài chính khủng hoảng rủi ro không mong muốn cục bộ bong bóng hơn 20 năm trước đó, vốn chẳng có cụm từ cải cách cách thao tác, công ty cũng luôn có thể có thật nhiều tiền nên nhân viên cấp dưới xem việc làm thêm một cách không bình thường là một việc thông thường. Thế nhưng thời đại này đã qua rồi.
C trong QCD
Các kỹ sư IT khi thao tác cần ý thức được về QCD.
- Q.=QualityC=Cost, đó đó là effortD=Delivery
Bài viết này sẽ nói về chữ C trong QCD.
Tầm quan trọng của việc estimate effort
Trước khi khởi đầu làm task, thứ nhất phải tiến hành estimate effort để làm task đó.
Như trên tôi có nói, nếu là một kỹ sư IT thao tác chuyên nghiệp thì sẽ không còn đổ thời hạn vô hạn vào task, mà phải số lượng giới hạn về thời hạn hoàn toàn có thể bỏ ra cho task đó. Thêm vào đó, 1 task có khi phải thực thi tuy nhiên tuy nhiên với task khác, nếu bỏ ra effort nhiều hơn nữa dự tính để làm 1 task, thì không đủ effort để làm task khác, và kết quả là tiến độ task sẽ bị chậm.
Vậy nên thứ nhất phải chốt được Giá trị ước tính cho effort làm task. Ngoài ra còn phải khiến giá trị ước tính (effort est) này sẽ không còn vượt quá effort sẽ sử dụng thực tiễn, nên việc làm estimate này thực tiễn là task có độ khó cao mà nhiều người cảm thấy trở ngại vất vả.
Tóm lại, quan trọng là đạt được:
1Effort thực tiễn < Effort ước tính
Nếu lỡ như effort thực tiễn vượt quá effort estimate mà chỉ có cách tiếp tục cho tới lúc hoàn thành xong, effort để hoàn thành xong những task khác hạ xuống mà cũng không moi đâu ra được effort tương hỗ update thì dev sẽ bị dồn vào thế trở ngại vất vả.
Nói chung effort estimate đó đó là cái bảo về chính bản thân mình mình nên quan trọng là không để nó to nhiều hơn effort thực tiễn. Nếu effort thực tiễn mà vượt quá effort estimate thì đại khái trách nhiệm thuộc về người đã đưa ra estimation.
Những case không cần estimate effort (?)
Cần để ý quan tâm lúc không estimate effort mà nhận yêu cầu từ cấp trên kiểu như:
- Dự án gấp, hãy làm trong MM/DD nhé.
Khả năng là đang ưu tiên lịch delivery nên buộc phải thực thi với effort cố định và thắt chặt cho tới lúc release. Nếu đó là việc mà tuân Theo phong cách lung tung cũng không sao thì có lẽ rằng không cần estimate thật, nhưng tôi không khuyến khích điều này.
Cách estimate
Khái quát
Việc biểu lộ estimate ra bằng công thức một cách logic là rất quan trọng. Dở nhất là estimate tuỳ tiện. Ví dụ việc làm của kỹ sư IT là lập trình viên thì hãy để bạn ấy estimate cho fix bug ứng dụng. Ví dụ với cách estimate như này: Nói chung chưa làm thì chưa chắc như đinh nhưng chắc khoảng chừng 3 ngày.
3 ngày nên effort ước tính sẽ là 3 man-day (24h). Tuy nhiên số lượng nó lại không còn một cơ sở nào cả nên không còn tính tin tưởng. Nhưng nếu đấy là kết luận của một kỹ sư có kinh nghiệm tay nghề thì lại không còn yếu tố gì. Vì tính tin cậy tới từ trực giác của một người dân có trên kinh nghiệm tay nghề chứ không phải một số trong những lượng được đưa ra tùy tiện. Để tiến hành estimate có độ đúng chuẩn cao, không đại khái, thì nên để ý quan tâm những điểm quan trọng sau.
- Chia nhỏ task và đưa ra từng số lượng nhỏFeedback lại thành tích trong quá khứCộng thêm bufferNhờ cấp trên check chéo
Chia nhỏ task
Nếu tăng trưởng ứng dụng theo sở trường thì thường rất triệu tập vào code, cơ bản sẽ có được flow như sau:
- Điều tra nguyên nhân bugSửa code phần có bugCho hoạt động và sinh hoạt giải trí để confirm sửa đổi
Tuy nhiên khi thao tác trang trọng thì những quy trình sẽ có được nhiều thay đổi. Tùy vào từng công ty và dự án công trình bất Động sản mà văn hóa truyền thống sẽ rất khác nhau nhưng thường có flow như sau:
- Điều tra nguyên nhân bugSửa đoạn code có bugChạy chương trình, confirm sửa đổi Nếu là việc làm thì những quy trình sẽ thay đổi quá nhiều. Tùy công ty, tùy dự án công trình bất Động sản mà sẽ rất khác nhau nhưng thường theo flow như sau:Điều tra nguyên nhân bugPhán đoán xem có phải nguyên nhân gốc rễ không. Nếu không thì quay trở lại 1.Đánh giá tại sao phát sinh bugXem xét phương pháp sửa bug. Sửa sao cho phạm vi ảnh hưởng là nhỏ nhấtNếu là bug về mặt thiết kế cấu trúc thì nên phải sửa lại designSửa source codeTiến hành review chéo. Làm 5,6 lần trước lúc hoàn thành xong.Tiến hành unit test với chỗ đã chỉnh sửaTiến hành funtion test ở đoạn chỉnh sửaTiến hành regression test ở đoạn sửa đổi Như trên, bạn phải hiểu rằng không riêng gì có đơn thuần và giản dị sửa source code cho xong là được. Chỉ một từ fix bug thôi nhưng được chia nhỏ làm nhiều đầu mục. Mình sẽ phải estimate cho từng đầu mục đó.
ItemEffort(H)Điều tra nguyên nhân8Xem xét cách fix3Sửa design2Sửa code2Tạo TCs2Review2Unit test3Funtion test5Test quy hồi3Tổng30
(còn tiếp)
Chia sẻ nội dung bài viết ngay
Nguồn nội dung bài viết : Viblo
Reply
7
0
Chia sẻ
Clip Cách tính Man_day ?
Bạn vừa Read Post Với Một số hướng dẫn một cách rõ ràng hơn về Clip Cách tính Man_day tiên tiến và phát triển nhất
Chia Sẻ Link Tải Cách tính Man_day miễn phí
You đang tìm một số trong những ShareLink Download Cách tính Man_day miễn phí.
Giải đáp vướng mắc về Cách tính Man_day
Nếu You sau khi đọc nội dung bài viết Cách tính Man_day , bạn vẫn chưa hiểu thì hoàn toàn có thể lại phản hồi ở cuối bài để Mình lý giải và hướng dẫn lại nha
#Cách #tính #Manday