Kiểm điểm ngang quyền
Để cải tiến chất lượng và giảm lỗi, người phát triển thường đề nghị các thành viên khác trong tổ kiểm điểm công việc của họ xác định liệu họ có khiếm khuyết hay không. Lí do là để tránh “thiên lệch cá nhân” vì nếu người phát triển làm kiểm điểm riêng của họ, họ có thể đi theo cùng logic mà họ quen làm việc này và sẽ không có khả năng phát hiện ra lỗi nào họ đã phạm phải. Người khác có thể làm tốt hơn trong việc tìm khiếm khuyết vì người đó có cảnh quan khác. Trong “kiểm điểm ngang quyền,” thành viên tổ kiểm tra công việc của nhau và cung cấp phản hồi cho tác giả. Kiểm điểm ngang quyền có thể là không chính thức hay chính thức, tuỳ theo chủ định của kiểm điểm.
Trong “kiểm điểm không chính thức” tác giả đề nghị một thành viên tổ kiểm tra lại công việc của mình. Người đó không biết thành viên kia của tổ tiến hành kiểm điểm ra sao và cuộc kiểm điểm toàn diện tới mức nào. “Kiểm điểm không chính thức” phụ thuộc vào tri thức và kĩ năng của người kiểm điểm cho nên kết quả biến thiên lớn. Một số làm việc tốt nhưng người khác có thể không. Khi kết thúc, người kiểm điểm có thể nói cho tác giả về số khiếm khuyết hay lỗi mà tác giả phải sửa.
Trong “Lập trình cặp đôi” (phần lớn dùng trong Lập trình cực đoan) hai người phát triển làm việc trên cùng sản phẩm đồng thời ở cùng một chỗ. Một người làm công việc, người kia quan sát và cung cấp bình luận, sau một thời gian họ đổi bên. Ý tưởng là hai người tốt hơn một người và điều đó giúp thảo luận tốt hơn giữa các thành viên tổ, và cung cấp cơ hội cho kiểm điểm liên tục các ý tưởng của nhau. Trong lập trình cặp đôi, mọi dòng mã đều được viết bởi hai người làm việc cùng nhau, điều dẫn tới sản phẩm chất lượng cao hơn. Lập trình cặp đôi có thể được dùng để tạo ra bất kì sản phẩm phần mềm nào, không chỉ mã. Từ cách nhìn “lập trình cực đoan,” lập trình cặp đôi thúc đẩy cộng tác, làm việc tổ, và cam kết chung về chất lượng sản phẩm.
Trong “giám định phần mềm” hay “kiểm điểm chính thức” tổ dự án tuân theo qui trình được xác định rõ với các vai trò đặc biệt được phân công cho riêng từng người tham gia. Qui trình giám định có vài pha: lập kế hoạch, chuẩn bị, kiểm điểm, làm lại việc, và theo dõi. Trong kiểu kiểm điểm này, các thành viên tổ phải được đào tạo trong qui trình giám định và có khả năng thực hiện các vai trò khác nhau. Giám định phần mềm bao giờ cũng tuân theo danh sách kiểm các khiếm khuyết thông thường được thấy trong các kiểu sản phẩm phần mềm khác nhau, các qui tắc để tiến hành kiểm điểm, và các kĩ thuật phân tích khác nhau để tìm khiếm khuyết. Tổ kiểm điểm thường bao gồm một người giám sát, người quản lí cuộc kiểm điểm; tác giả, người được kiểm điểm; ít nhất hai người kiểm điểm, người tiến hành việc kiểm điểm; và một người ghi, người làm tài liệu các vấn đề khi họ lôi ra. Người kiểm điểm nhận công việc ít nhất vài ngày hay một tuần trước ngày kiểm điểm để cho họ có thể chuẩn bị cho kiểm điểm. Người kiểm điểm xem xét công việc trước để hiểu nó và tìm vấn đề. Trong cuộc họp, người giám sát xem qua tài liệu cùng người kiểm điểm, người nêu ra vấn đề và chỉ ra khiếm khuyết có thể. Người giám sát giúp tổ kiểm điểm đạt tới cùng cách diễn giải của từng công việc. Tác giả lắng nghe cẩn thận các vấn đề được nêu ra nhưng không tranh cãi với những lời bình luận. Người ghi làm tài liệu mọi vấn đề được nêu ra trong cuộc họp. Đến cuối cuộc kiểm điểm, những người kiểm điểm rời khỏi cuộc họp. Người giám sát và tác giả xem qua danh sách các vấn đề và thảo luận về cuộc kiểm điểm và đồng ý sửa các vấn đề được nhận diện. Trong khi làm lại công việc, tác giả sửa các vấn đề (khiếm khuyết, lỗi v.v.) Đảm bảo chất lượng phần mềm kiểm điểm việc làm lại và so sánh với danh sách để chắc rằng mọi vấn đề đã được sửa trước khi nó được đưa ra.
Kiểm điểm chính thức (giám định phần mềm) là hiệu quả ở chỗ tìm khiếm khuyết hơn là kiểm điểm không chính thức nhưng nó yêu cầu nhiều thời gian hơn và cần đào tạo để làm nó cho đúng. Người quản lí dự án phải lập kế hoạch cho mọi kiểm điểm, cả không chính thức và chính thức trong khi lập kế hoạch của dự án.
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
