Sáng nay sức hơi trâu, tiếp tục chia sẻ về cách thức triển khai estimate một dự án.
Khi nhận một dự án , hay một công đoạn nào đó , ví dụ như thiết kế, phát triển, hay thực thi test . Sau khi tìm hiểu về dự án, tính khả thi có thực hiện được hay không? Tiếp đến cần phải cung cấp cho khách hàng thấy bản schedule (WBS) triển khai công việc. Và để làm được thì đòi hỏi kỹ năng estimate.
Kỹ năng này là kỹ năng bắt buộc phải có đối với vị trí project manager. Tuy nhiên để trở thành một SE xuất sắc, thì cũng nên học tập và trau dồi kỹ năng này. Để esimate được dự án, đòi hỏi người làm estimate phải có hiểu biết về kỹ thuật, kinh nghiệm triển khai về dự án tương tự. Một số công ty mà mình đã có cơ hội được làm việc như TOSHIBA, DTS thì estimate dựa trên các chỉ số dữ liệu các dự án tương tự, việc này sẽ giảm tải, và bớt phụ thuộc vào các key member .Và số liệu này tất nhiên sẽ lấy từ các kho dữ liệu từ Redmine, Jira, hay một tool quản lý của công ty. Những công ty lớn, có quy trình triển khai phần mềm tốt đều thực thi input đầu vào rất nghiêm ngặt đảm bảo độ chính xác khá cao.
Nội dung chia sẻ sử dụng dữ liệu được chiết xuất từ các tool quản lý để estimate mình sẽ chia sẻ ở một bài viết khác, còn bài viết này sẽ hướng dẫn một cách nông dân hơn, tự tay estimate là như thế nào !
Điều kiện input là người estimate phải hiểu được công việc được giao, đã từng có kinh nghiệm thực thi công việc tương tự. Trường hợp không đảm bảo input đầu vào thì mình nghĩ nên nhờ hoặc báo cáo sếp tình trạng thực tế để có phương án dự phòng.
Kinh nghiệm để estimate là ” Chia để trị ” – công thức này áp dụng một cách triệt để trong khâu phân tích yêu cầu, cũng như việc bóc tách source, tính cost trên mỗi đơn vị nhỏ nhất.
Cụ thể dự án sắp tới, Satou giao cho mình care công việc convert, fix lỗi HTML5.
Áp dụng công thức trên, mình đã comfirm với Satou : okie HTML5 tao đã từng làm, hãy cung cấp cho tao source và tài liệu mô tả yêu cầu, để tao điều tra xem như thế nào, hẹn hôm sau tao sẽ báo kết quả. Mình chia sẻ một chút về cách thức làm việc của người Nhật, khi đưa ra đề xuất – luôn phải có thời gian comfirm khi nào trả lời. Thời gian comfirm thực tế có thể bị sai lệch so với dự định, cái mấu chốt ở đây là phải có thời gian xác nhận tình trạng công việc – người Nhật cần thế, trường hợp kết quả điều tra lâu hơn dự định , thì cần phải báo cáo tình trạng, nguyên nhân và cách xử lý càng sớm càng tốt cho người quản lý.
Quay lại nội dung estimate trên, có câu hỏi là ” tôi đã làm những gì để trả lời cho Satou về kết quả điều tra esimate vào ngày hôm sau? ”
Điều đầu tiên là tôi điều tra về tài liệu mô tả. Okie đây rồi, có một file mô tả danh sách các lỗi cú pháp HTML5 trong dự án – có 21 lỗi tất cả, tất nhiên mỗi lỗi mẹ sẽ đẻ ra một list các lỗi con, nên tất nhiên số lỗi sẽ nhiều hơn thế.
Đầu vào khá clear rồi, tiếp đến phải điều tra source. Dự án này dùng Java, vậy sử dụng eclips để deploy thôi, sau khi deploy okie. Tiếp đến , mình không quên cài thêm công cụ editor thần thánh sakura, bởi sakura có chức năng grep cực mạnh, rất nhiều option tuyệt vời.
Chia nhỏ từng lỗi trong 21 lỗi về HTML5 , nhặt từng key cho vào filter đầu vào sakura để grep . Mục đích là để tái hiện các lỗi này trong source , khi search ra kết quả lỗi , mình check ngược lại source đọc sơ qua , phán đoán xem nguyên nhân lỗi là gì. Okie đây rồi, hệ thống nó sử dụng HTML4 !
Cứ thế từng chút từng chút một, bóc tách lần lượt hết các lỗi trong list file mô tả. Kết quả đưa ra là có 4 lỗi mình không tái hiện được – warring trong email báo cáo cho Satou.
Tiếp theo, “chia để trị ” cho việc phân tích source. Các lỗi HTML5 này nằm hết trong các file JSP , đầu tiên mình sẽ đếm có bao nhiêu file JSP. Kết quả là 629 file, trả lời cho câu hỏi ” vậy cần bao nhiêu thời gian để xử lý cho một file ?” tất nhiên mỗi file sẽ có thời gian khác nhau, sự khác nhau đến từ số lượng dòng code. Okie, tiếp đến hỏi thánh Google “eclipe 行数 カウント” thánh trả lời hãy sử dụng plugin bên dưới, cùng với hướng dẫn rất chi tiết. Làm theo step by step màn hình thống kê rất chi tiết về số dòng code thực tế, số dòng comment, tổng số dòng code…, ola tuyệt vời, mình chỉ việc export ra file excel để chuẩn bị làm file estimate.
Công việc cuối cùng là căn cứ vào các lỗi mà mình đã tái hiện ở bước đầu, kết hợp với số lượng dòng code ở bước 2, ước lượng ra từng hệ số thời gian xử lý tương ứng với từng file code. Xong xuôi SUM tính tổng time, rồi tính ra cost theo ngày (人日), cost theo tháng (人月).
Việc đơn giản và hạnh phúc nhất là email báo cáo kết quả cho Satou. Tất nhiên, không quên note rõ ràng điều kiện estimate được (前提条件), 4 lỗi không tái hiện được. Và gửi file kết quả estimate điều tra !
Khi nhận một dự án , hay một công đoạn nào đó , ví dụ như thiết kế, phát triển, hay thực thi test . Sau khi tìm hiểu về dự án, tính khả thi có thực hiện được hay không? Tiếp đến cần phải cung cấp cho khách hàng thấy bản schedule (WBS) triển khai công việc. Và để làm được thì đòi hỏi kỹ năng estimate.
Kỹ năng này là kỹ năng bắt buộc phải có đối với vị trí project manager. Tuy nhiên để trở thành một SE xuất sắc, thì cũng nên học tập và trau dồi kỹ năng này. Để esimate được dự án, đòi hỏi người làm estimate phải có hiểu biết về kỹ thuật, kinh nghiệm triển khai về dự án tương tự. Một số công ty mà mình đã có cơ hội được làm việc như TOSHIBA, DTS thì estimate dựa trên các chỉ số dữ liệu các dự án tương tự, việc này sẽ giảm tải, và bớt phụ thuộc vào các key member .Và số liệu này tất nhiên sẽ lấy từ các kho dữ liệu từ Redmine, Jira, hay một tool quản lý của công ty. Những công ty lớn, có quy trình triển khai phần mềm tốt đều thực thi input đầu vào rất nghiêm ngặt đảm bảo độ chính xác khá cao.
Nội dung chia sẻ sử dụng dữ liệu được chiết xuất từ các tool quản lý để estimate mình sẽ chia sẻ ở một bài viết khác, còn bài viết này sẽ hướng dẫn một cách nông dân hơn, tự tay estimate là như thế nào !
Điều kiện input là người estimate phải hiểu được công việc được giao, đã từng có kinh nghiệm thực thi công việc tương tự. Trường hợp không đảm bảo input đầu vào thì mình nghĩ nên nhờ hoặc báo cáo sếp tình trạng thực tế để có phương án dự phòng.
Kinh nghiệm để estimate là ” Chia để trị ” – công thức này áp dụng một cách triệt để trong khâu phân tích yêu cầu, cũng như việc bóc tách source, tính cost trên mỗi đơn vị nhỏ nhất.
Cụ thể dự án sắp tới, Satou giao cho mình care công việc convert, fix lỗi HTML5.
Áp dụng công thức trên, mình đã comfirm với Satou : okie HTML5 tao đã từng làm, hãy cung cấp cho tao source và tài liệu mô tả yêu cầu, để tao điều tra xem như thế nào, hẹn hôm sau tao sẽ báo kết quả. Mình chia sẻ một chút về cách thức làm việc của người Nhật, khi đưa ra đề xuất – luôn phải có thời gian comfirm khi nào trả lời. Thời gian comfirm thực tế có thể bị sai lệch so với dự định, cái mấu chốt ở đây là phải có thời gian xác nhận tình trạng công việc – người Nhật cần thế, trường hợp kết quả điều tra lâu hơn dự định , thì cần phải báo cáo tình trạng, nguyên nhân và cách xử lý càng sớm càng tốt cho người quản lý.
Quay lại nội dung estimate trên, có câu hỏi là ” tôi đã làm những gì để trả lời cho Satou về kết quả điều tra esimate vào ngày hôm sau? ”
Điều đầu tiên là tôi điều tra về tài liệu mô tả. Okie đây rồi, có một file mô tả danh sách các lỗi cú pháp HTML5 trong dự án – có 21 lỗi tất cả, tất nhiên mỗi lỗi mẹ sẽ đẻ ra một list các lỗi con, nên tất nhiên số lỗi sẽ nhiều hơn thế.
Đầu vào khá clear rồi, tiếp đến phải điều tra source. Dự án này dùng Java, vậy sử dụng eclips để deploy thôi, sau khi deploy okie. Tiếp đến , mình không quên cài thêm công cụ editor thần thánh sakura, bởi sakura có chức năng grep cực mạnh, rất nhiều option tuyệt vời.
Chia nhỏ từng lỗi trong 21 lỗi về HTML5 , nhặt từng key cho vào filter đầu vào sakura để grep . Mục đích là để tái hiện các lỗi này trong source , khi search ra kết quả lỗi , mình check ngược lại source đọc sơ qua , phán đoán xem nguyên nhân lỗi là gì. Okie đây rồi, hệ thống nó sử dụng HTML4 !
Cứ thế từng chút từng chút một, bóc tách lần lượt hết các lỗi trong list file mô tả. Kết quả đưa ra là có 4 lỗi mình không tái hiện được – warring trong email báo cáo cho Satou.
Tiếp theo, “chia để trị ” cho việc phân tích source. Các lỗi HTML5 này nằm hết trong các file JSP , đầu tiên mình sẽ đếm có bao nhiêu file JSP. Kết quả là 629 file, trả lời cho câu hỏi ” vậy cần bao nhiêu thời gian để xử lý cho một file ?” tất nhiên mỗi file sẽ có thời gian khác nhau, sự khác nhau đến từ số lượng dòng code. Okie, tiếp đến hỏi thánh Google “eclipe 行数 カウント” thánh trả lời hãy sử dụng plugin bên dưới, cùng với hướng dẫn rất chi tiết. Làm theo step by step màn hình thống kê rất chi tiết về số dòng code thực tế, số dòng comment, tổng số dòng code…, ola tuyệt vời, mình chỉ việc export ra file excel để chuẩn bị làm file estimate.
Công việc cuối cùng là căn cứ vào các lỗi mà mình đã tái hiện ở bước đầu, kết hợp với số lượng dòng code ở bước 2, ước lượng ra từng hệ số thời gian xử lý tương ứng với từng file code. Xong xuôi SUM tính tổng time, rồi tính ra cost theo ngày (人日), cost theo tháng (人月).
Việc đơn giản và hạnh phúc nhất là email báo cáo kết quả cho Satou. Tất nhiên, không quên note rõ ràng điều kiện estimate được (前提条件), 4 lỗi không tái hiện được. Và gửi file kết quả estimate điều tra !
Điều mình muốn chia sẽ ở topic này là công thức ” chia để trị ” áp dụng triệt để khi thực thi estimate. Hai là khi đưa ra bất cứ nhận định nào , thì phải dựa trên kết quả điều tra thực tế mà có !
No comments:
Post a Comment