Xin hỏi về cách đo
Hỏi: Tôi xin hỏi vấn đề sau, tôi muốn định nghĩa 1 số đo cho các dự án. Nhưng như tôi thấy, các số đo như UCP, LOC, FP chỉ đo kích cỡ giai đoạn phát triển, hay nói cách khác là kích cỡ sản phẩm hơn là kích cỡ một dự án. Trong khi, ở cương vị 1 Quản trị dự án, tôi thấy có nhiều giai đoạn như giai đoạn lấy yêu cầu hay giai đoạn triển khai rất khó tính kích cỡ được, mà lúc Monitor dự án tôi rất muốn tính được khối lượng (kích cỡ) hoàn thành (dựa trên khối lượng dự án chứ khối lượng sản phẩm thì không đầy đủ). Liệu có cách đo nào tính được kích cỡ toàn dự án, nhằm đưa ra số đo khối lượng hoàn thành cho từng tuần không?
Đáp: Rất khó tính toán “kích cỡ toàn bộ” của dự án phần mềm vì có nhiều yếu tố tham gia vào như ngôn ngữ lập trình (như, C hay Java), yếu tố độ phức tạp (đơn giản hay phức tạp với chu trình và tính toán phức tạp), yếu tố miền (dựa trên Web, nhúng, hay ứng dụng doanh nghiệp v.v.), yếu tố qui trình hay vòng đời (thác đổ, xoáy ốc, làm bản mẫu, gia tăng v.v), các phương pháp (cấu trúc hay hướng đối tượng) và khách hàng (nội bộ và ngoại bộ) và mức độ truyền thông được yêu cầu. Về căn bản, ước lượng kích cỡ dự án tuỳ thuộc vào môi trường trong đó dự án được thực hiện.
Kĩ thuật kích cỡ mà bạn nhắc tới CHỈ dùng để ước lượng sản phẩm phần mềm, KHÔNG phải là kích cỡ toàn bộ dự án. Dòng mã (LOC) đo số các mã có thể được đếm trong phần mềm. Nó có ích chỉ cho nền công nghệ trên đó phần mềm được xây dựng nhưng LOC biến thiên cho các ngôn ngữ lập trình khác nhau. Điểm chức năng (FP) đo chức năng công việc. Kích cỡ được đo qua phương pháp FP là độc lập với ngôn ngữ lập trình hay công nghệ và có tác dụng tốt với ứng dụng nghiệp vụ nhưng không cho các ứng dụng khác như phần mềm nhúng hay phần mềm dựa trên web (nhiều hiển thị màn hình và dẫn hướng). Điểm đối tượng (OP) đo kích cỡ phần mềm bằng việc đếm số màn hình, báo cáo và giao diện nhưng có thể không có tác dụng tốt cho nghiệp vụ (nhiều tính chức năng) hay ứng dụng khoa học (nhiều xử lí)
Có những chức năng hỗ trợ trong mọi dự án phần mềm mà thường KHÔNG được tính tới trong các phương pháp này như các hoạt động quản lí dự án, hoạt động kĩ nghệ yêu cầu, hoạt động trao đổi, hoạt động đào tạo, hoạt động tổ, hoạt động gặp gỡ khách hàng, hoạt động báo cáo, hoạt động làm tài liệu, hoạt động đóng dự án, hoạt động kiểm điểm, hoạt động đảm bảo chất lượng, hoạt động cấu hình, hoạt động hỗ trợ hệ thống, và nhiều thứ nữa. Đó là lí do tại sao rất khó tính “kích cỡ toàn thể” của dự án phần mềm.
Có cách đơn giản mà nhiều người quản lí dự án thường làm. Họ tính toán kích cỡ của việc phát triển dự án (LOC, FP, OP v.v) rồi thêm 25% (cho các dự án nhỏ và đơn giản) tới 45% (cho dự án lớn và phức tạp) để đi tới “kích cỡ dự án toàn bộ”. Đây là “tổng phí” cho các chức năng hỗ trợ mà phải được đưa vào.
Để tính đúng kích cỡ dự án toàn bộ, bạn có thể thêm mọi yếu tố vào trong bản kế hoạch dự án, cũng như phần đệm cho trường hợp dự phòng nào đó. Sau đây là một cách đơn giản mà tôi thường dùng để lập ngân sách cho dự án. (Lưu ý: Đây không phải là phương pháp khoa học được dạy trong trường nhưng dựa trên kinh nghiệm. Một số người có thể đồng ý hay có thể không đồng ý. Tất nhiên, chúng ta không thảo luận cách tốt nhất hay cách đúng ở đây.)
Tôi thường bắt đầu phát triển “ngân sách dự án toàn bộ” bằng việc nhìn vào toàn thể dự án như một tổng thể. Không chỉ hoạt động phát triển phần mềm (các pha vòng đời phần mềm). Tôi ước lượng nỗ lực của điều phải được làm, cách nó được làm, và thời gian làm nó. Có hai chi phí chính: lao động và vật tư (phần cứng, phần mềm, trang thiết bị v.v.) nhưng với hầu hết dự án phần mềm, lao động là yếu tố chi phí then chốt.
Tôi chia toàn thể dự án thành nhiều hoạt động chi tiết để ước lượng nỗ lực và chi phí toàn bộ. Chẳng hạn: lập kế hoạch tiền dự án, hợp nhất yêu cầu, phân tích yêu cầu, kiểm điểm yêu cầu, làm tài liệu yêu cầu, lập kế hoạch dự án, hình thành tổ, đào tạo tổ, đào tạo dự án, kiểm điểm yêu cầu, phân công công việc tổ, kiến trúc hệ thống, kiểm điểm kiến trúc, thiết kế chi tiết, kiểm điểm thiết kế, thực hiện dự án (viết mã), giám định mã, kiểm điểm mã, chiến lược kiểm thử, lập kế hoạch kiểm thử, kiểm điểm kiểm thử, kiểm thử dự án, kiểm thử tích hợp, kiểm thử chấp nhận của khách hàng và hoạt động hỗ trợ dự án (đảm bảo chất lượng, quản lí cấu hình, hỗ trợ mạng, hỗ trợ phần cứng, hỗ trợ tài liệu v.v.).
Với từng hoạt động, tôi xác định bao nhiêu người sẽ được tham gia và nó sẽ mất bao nhiêu thời gian. Tất nhiên, nó chỉ là ước lượng đại thể vì khó tính được con số chính xác nỗ lực. Sau khi đi tới một ước lượng, tôi thêm quãng 20% tới 30% phần đệm cho từng hoạt động dành cho dự phòng (để giảm rủi ro).
Chẳng hạn: Lập kế hoạch tiền dự án yêu cầu hai cuộc họp để hiểu mong đợi của quản lí và nhu cầu của khách hàng. Nó thường bao gồm ba người: người quản lí dự án, người kiến trúc sư hệ thống và người quản trị hành chính dự án để làm tài liệu các chi tiết. Điều này yêu cầu hai cuộc họp; một cuộc với người quản lí cấp cao và một cuộc với khách hàng, mỗi cuộc có thể mất một giờ. Với ba người và hai giờ, tôi có thể tính ra chi phí bằng việc nhân tiền trả theo giờ với ba (để đơn giản giả sử cả ba đều có cùng giá $10 đô la một giờ. Chi phí tổng cho hoạt động này là: $10X3X2 = $60. Tôi thêm vùng đệm 30% cho nó cho nên chi phí toàn bộ cho hoạt động này là $60 + $18 = $78.
Cùng điều đó có thể được áp dụng cho các hoạt động khác cho nên bằng tính toán ra được tổng chi phí lao động cho từng hoạt động; tôi đi tới tổng chí phí lao động cho toàn thể dự án. Một số dự án có thể yêu cầu chi phí vật tư như phần cứng, phần mềm, trang thiết bị hay công cụ. Chằng hạn, từng người phát triển cần dùng công cụ phần mềm. Tôi phân công từng người một giấy phép cho công cụ và nhân chi phí giấy phép lên theo số người phát triển. Nếu một giấy phép là $10 trên người dùng, tôi có 100 người phát triển, nhân $10X 100 được chi phí $1000. Bằng việc bổ sung thêm phần đệm 30% tổng là $1300. Cùng điều này có thể dược dùng cho chi phí trang thiết bị. Bằng việc biết bao nhiêu trang thiết bị được cần và chi phí cho từng thứ, tôi có thể tính tổng chi phí.
Bằng việc tổ chức các nỗ lực này trong một lịch theo tuần, tôi có thể giám sát điều tôi đã lập kế hoạch và điều thực sự xảy ra (được lập theo kế hoạch so với thực tại) cũng như dõi vết tiền tôi đã tiêu (được lập theo kế hoạch so với thực tại). Tôi bao giờ cũng lưu chúng chúng trên trang tính như Excel rồi đến cuối dự án, tôi có “dữ liệu lịch sử” về ước lượng của tôi tốt thế nào. Tôi càng có nhiều “dữ liệu lịch sử”, tôi càng có thể điều chỉnh các ước lượng của tôi cho các dự án tương lai. Đây là cách tôi học về ước lượng, đo và giám sát dự án phần mềm. Không cái gì tốt hơn là thực hành thức tế để thu được kinh nghiệm.
Tôi chắc chắn những người khác có cách riêng của họ để tính “kích cỡ toàn bộ” của dự án phần mềm dựa trên kinh nghiệm riêng của họ.
Tác phẩm, tác giả, nguồn
- Tác phẩm: Quản lý dự án
- Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
- Wiki hóa: https://kipkis.com
