Kiểm điểm ngang quyền

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.

—-English version—-

Peer Review

To improve quality and to reduce defects, developers often ask other team members to review their work to determine whether they have defects or not. The reason is to avoid “personal bias” because if developers are doing their own review, they may follow the same logic that they used to do the work and will not be able to detect any error that they made. Another person could do better in finding defects because he has different perspective. In “Peer Review”, team members examine each other’s work and provide feedback to the authors. Peer Review can be informal or formal, depending on the purpose of the review.

In an “Informal Review” the author asks one team member to examine his work. He does not know how the other team member conducts the review and how comprehensively the review is done. The “Informal Review” is depending on the knowledge and skill of the reviewer so the result varies greatly. Some do a good job but other may not. When finish, the reviewer can tell the author the number of defects or bugs that he must fix.

In “Pair programming” (Mostly use in Extreme Programming) two developers work on the same product simultaneously at the same place. One do the work, the other observes and provide comments, after a while they switch side.  The idea is two persons is better than one and it helps better discussion between team members, and provide opportunity for continuous review of each person’s ideas. In Pair programming, every line of code is written by two people working together which leads to higher quality products. Pair programming can be used to create any software product, not just code. From the “Extreme programming” view, pair programming promotes collaboration, teamwork, and a shared commitment to the quality of the product.

In “Software Inspection” or “Formal Review” the project team follows a well-defined process with specific roles assigned to individual participants. The inspection process has several phases: Planning, Preparation, Review, Rework, and Follow-up. In this type of review, team members should be trained in the inspection process and be able to perform different roles. Software Inspection always follows a checklists of common defects found in different types of software products, rules for conduct review, and various analytical techniques to search for defects. The review team often consists of a Moderator who manage the review; the Author whose work is being reviewed; at least two Reviewers who conduct the review; and a Recorder who document the issues as they are brought up. Reviewers receive the work at least few days or a week before the review date so they can prepare for the review. Reviewers examine the work in advance to understand it and to find problems. During the meeting, the Moderator goes over the material with reviewers, who raise issues and point out possible defects. The Moderator helps the review team reach the same interpretation of each work. The author listens carefully to the issues raised but do not argue with the comments. The recorder document all issues raised during the meeting. At the end of the review, the reviewers leave the meeting. The Moderator and the Author go over the issue lists and discuss the review and agree to fix the problems identified. During rework, the author fixes the problems (Defects, bugs etc.) Software Quality Assurance reviews the rework and compare with the list to make sure that all problems have been fixed before allow it to be released.

Formal review (Software Inspections) is more effective at finding defects than informal review but it requires more time and trainings to do it correctly. The project manager must plan all reviews, both informal and formal during the planning of the project.