Vai trò quan trọng của review

Bạn có bỏ tiền ra mua một sản phẩm mà không biết chất lượng thế nào không? Trừ khi nó quá rẻ kiểu 10K, 50K nếu không dùng đc vứt đi còn lại đa phần chúng ta đều ko chấp nhận bỏ tiền mua bực vào người.
Với phần mềm cũng tương tự vậy, bạn có thấy không thoải mái khi tiếp nhận 1 tài liệu cẩu thả hoặc 1 đoạn source code thiếu logic từ người khác không?
Khách Hàng chắc chắn không muốn bỏ tiền ra cho một thứ chất lượng không ổn định thậm chí gây sai sót thiệt hại. Vậy làm thế nào để tạo ra phần mềm chất lượng tốt?

1. Việc đảm bảo chất lượng phần mềm và các vấn đề thời nay

1.1 Môi trường kinh doanh và bài toán

Hiện nay thời gian phát triển phần mềm ngắn hơn trước nhiều thường là nửa năm hoặc ngắn hơn nữa là 3 tháng. Thị trường đồng thời yêu cầu một môi trường phát triển chi phí thấp hơn, tốc độ nhanh hơn, mà độ tin cậy lại phải cao hơn so với trước.

Vì thời gian ngắn nên spec chưa chốt hoặc chưa rõ ràng mà vẫn phải tiến hành phát triển. Khá nhiều project phải lược bỏ quy trình và các công đoạn đảm bảo chất lượng chẳng hạn như ko quản lý risk, lược bớt review, bàn giao sản phẩm ở mức độ prototype chứ chưa đc thiết kế kỹ, test kỹ.

Một vấn đề nữa do thiếu nguồn lực nên các công ty phát triển phần mềm thường phải chia tách module việc và hợp tác với partner hay thuê outsource ở ngoài nước, phó thác cho họ phát triển cũng như đảm bảo chất lượng. Điều này dẫn đến hệ quả có nhiều TH phát sinh vấn đề chất lượng, sự cố và phải xử lý thêm ngay cả sau khi đã phát hành ra thị trường.

Chúng ta đều biết việc xử lý sự cố (incident) sau phát hành thường kéo dài hơn dự kiến, mất nhiều công sức confirm của nhiều bên, thành viên dự án mệt mỏi chán nản, chi phí phát sinh đội hơn nhiều và rất dễ phát sinh sự cố phái sinh (degrade)…

Vì vậy việc đưa ra cơ chế review và quản lý rủi ro một cách phù hợp với tình hình mới trở nên cần thiết hơn bao giờ hết. Việc cắt giảm hết hoặc thực hiện review nhưng ko đầy đủ hay quản lý rủi ro chậm trễ ko đối ứng kịp thời là nguyên nhân chính gây ra vấn đề.

1.2 Cách suy nghĩ đảm bảo chất lượng ở công đoạn test

Có một hướng suy nghĩ đảm bảo chất lượng theo kiểu [Hãy test nhiều hơn nữa so với trước]. Tuy nhiên nếu cách thành phần phần mềm không được tốt ta sẽ tốn khá nhiều công sức test so với ước lượng ban đầu. Mặt khác nếu thời hạn giao hàng quá gấp ta cũng không thể bố trí test nhiều cho dù muốn.

Vì vậy cách hiệu quả hơn là phải quay ngược lại cải tiến các công đoạn phía trước đó như phân tích yêu cầu, thiết kế, lập trình.

2. Vai trò của review trong phát triển phần mềm

2.1 Review là gì?

Ai cũng có thể mắc sai sót, nhầm lẫn lớn nhỏ bởi những vấn đề về con người, quy trình, kinh nghiệm vân vân. Review là quá trình phát hiện, đề xuất cải tiến, loại bỏ vấn đề ở từng công đoạn phát triển để đưa sản phẩm đến trạng thái đủ tiêu chuẩn đi tiếp được sang công đoạn tiếp theo.

2.2 Có các loại hình review gì trong review?

Manager review: Review tổng thể dự án ở giai đoạn bắt đầu, đặt ra các tiêu chí, milestone vân vân

Status review: Review trạng thái dự án định kỳ milestone một cách tổng thể về vấn đề chi phí, lịch trình, chất lượng, sự thay đổi

Closing review: Review tiêu chuẩn đóng được dự án

Development review: Review ở từng công đoạn phát triển như Spec review, design review, Code review, Test review, Release review

2.3 Sự cần thiết của review

Chất lượng của sản phẩm phải được đảm bảo bằng các tiêu chuẩn và để đạt được các tiêu chuẩn đó phải đảm bảo chất lượng, độ chính xác ở từng khâu từ bắt đầu cho đến kết thúc. Ở phạm vi giai đoạn phát triển trong phần mềm nói một cách đơn giản thì phải đảm bảo từ các khâu:
Định nghĩa yêu cầu -> Phân tích yêu cầu -> Thiết kế cơ bản (code, test) -> Thiết kế chi tiết (code, test) -> Lập trình -> Unit Test -> Test -> Giao hàng (Release) -> Vận hành. bảo trì nâng cấp.

Ở từng khâu đó nếu chỉ tin tưởng giao cho 1 người làm bạn có đảm bảo người đó không có sai sót không? Chắc chắn không. Vậy để đảm bảo chất lượng bắt buộc phải yêu cầu bản thân người đó thực hiện self-review và tăng cường các góc nhìn khác bằng cách cross review, group review, …

2.4 Quan hệ giữa chi phí và công đoạn loại bỏ khiếm khuyết

Thời điểm phát hiện vấn đề tỷ lệ nghịch với công sức khắc phục vấn đề. Càng để muộn khắc phục càng mất công.

2.5 Review và Test khác nhau gì?

Môi trường: Review được thực hiện trên môi trường tĩnh như tài liệu, source code. Test được thực hiện trên môi trường động, thật như chương trình chạy, thiết bị, server.

Thời điểm: Review là trước khi vấn đề xảy ra. Test là sau khi vấn đề xảy ra.

2.6 Quan hệ giữa phát triển và review

Review tốt sẽ bớt 40%~60% công sức rework.

3. Những lý do khó khăn khi triển khai review và cách khắc phục

• Member không ý thức được một thiếu sót nhỏ, sai sót nhỏ của mình sẽ kéo theo hậu quả, chi phí tăng theo cấp số nhân.
  => Đào tạo tăng mindset.
• Member coi việc review là việc của người khác chứ không phải bản thân nên không thực hiện self-review.
  => Đào tạo tăng mindset. Đưa việc self-review vào quy trình và kiểm tra bằng checklist.
• KH hoặc đối tác thúc giục về mặt tiến độ nên team bỏ qua công đoạn review dẫn đến việc sau khi giao hàng lại phải re-work lại. Hệ quả là tiến độ tổng thể chậm thậm chí chậm hơn so với nếu review đầy đủ từ đầu.
  => Học cách từ chối một cách có biện luận, giải thích đầy đủ cho KH hiểu để không đánh đổi.
• Chỉ có người thực hiện hiểu và có skill làm công việc đó và cho rằng người khác không thể review giúp ích được gì.
  => Thay đổi cách giao việc để có nhiều hơn 1 người nắm được công việc, skill. Kể cả skill, công việc ít gặp không phổ biến thì người khác vẫn có thể review ở các góc độ khác mà không cần phải biết sâu.
• Thành viên dự án quá mỏng chỉ có một mình mà không có ai review cùng nhau.
  => Thay đổi cách giao việc và phân phối người, trao đổi effort giữa người A và B theo tỉ lệ 80% effort implement ~20% effort review. Việc này cũng tăng skill của từng member cộng giảm rủi ro nhân sự.

You need to login in order to like this post: click here