Ứng dụng nguyên lý 80:20 trong việc phát triển phần mềm

Những người làm quản lý thường không muốn phải suy nghĩ quá nhiều. Họ thích những nguyên tắc đơn giản, nhanh chóng và rõ ràng để tiếp cận vấn đề và định hướng chính xác. Càng đơn giản càng tốt. Một trong những nguyên lý thường được sử dụng là nguyên lý 80:20.

Thay vì làm nhiều mà kết quả thu được không đáng bao nhiêu, bạn hoàn toàn có thể đạt đươc hiệu quả cao hơn bằng cách làm việc thông minh hơn. Có thể thấy rõ tính ứng dụng của nguyên tắc 80:20 vào quá trình phát triển phần mềm. Ví dụ như, 80% cải tiến khi vận hành là nhờ việc tối ưu 20% code. Mặc dù tỉ lệ thực tế có thể vào khoảng 90:10 hay thậm chí 99:1, nhưng nguyên tắc này đều có tính chất áp dụng giống nhau.

 “80% người dùng chỉ sử dụng hết 20% tính năng của của phần mềm.” 

Điều này được rút ra từ nghiên cứu của Standish Group vào năm 2002:

• 45% các tính năng phần mềm chưa từng được sử dụng.
• 19% hiếm khi được sử dụng.
• 16% thỉnh thoảng được sử dụng
• Chỉ duy nhất 20% các tính năng được sử dụng thường xuyên.

Tương tự như đường cong về chi phí thay đổi, đây là một ví dụ khác về một sự thật hiển nhiên trong phát triển phần mềm và cần có thêm nhiều nghiên cứu để chứng minh.

Nghiên cứu này ảnh hưởng lớn tới Agile và Lean Development, khuyến khích mọi người tập trung vào việc tạo ra những tính năng có khả năng thương mại hóa tối thiểu hoặc những sản phẩm khả thi tối thiểu. Bắt đầu với những thứ nhỏ nhất nhưng được mọi người đánh giá thực sự quan trọng và cần thiết, ưu tiên những tính năng này và triển khai nhanh nhất có thể.

“80% kết quả đạt được đến từ 20% nguyên nhân”

Nghiên cứu gần đây nhất của Standish Group cho thấy rằng việc suy nghĩ nhỏ hơn và tạo ra ít hơn là chìa khóa nâng cao khả năng thành công của các dự án phát triển phần mềm. Trong khi hơn 70% các dự án nhỏ đưa ra sản phẩm thành công thì các dự án lớn hầu như không đạt được điều gì mà còn bị chậm tiến độ, lạm chi và bỏ qua những tính năng quan trọng.

Tuy nhiên, việc này dễ làm giảm giá trị và tính sáng tạo khi chúng ta chọn phương án quá an toàn. Phát triển 20% hoặc 50% của hệ thống thường sẽ không đủ để thành công. Bạn sẽ cần nhiều hơn thế để có thể thay đổi cách tư duy người dùng và tạo ra sản phẩm khiến cả thế giới khao khát.

80:20 Bugs và Testing

“80% các Bugs được tìm thấy trong 20% lượng code viết ra
90% lượng thời gian bị chết đến từ 10%các khuyết điểm (hoặc ít hơn)”

Bugs là một phần đi liền với code và đa số các vấn đề nghiêm trọng nhất đến từ một số ít bugs mà thôi.

“80% lỗi trong Windows và Office là do 20% trên tổng số các bugs phát hiện được gây ra”

Cần hiểu rõ những bugs nghiêm trọng nhất thường xuất hiện ở đâu và vì sao, từ đó đầu ư thời gian chủ yếu vào việc xác định cần phải làm gì để ngăn chặn chúng.

Một vài nghiên cứu đã cho thấy hầu hết các bugs bị phát hiện chỉ nằm trong 10-20% lượng code hay bị thay đổi thường xuyên nhất. Việc tìm ra một bug trong lượng code này đồng nghĩa với còn nhiều bugs khác cần được phát hiện và sửa chữa. Caper Jones nói rằng xử lý những code có rủi ro lỗi cao làm giảm đáng kể năng suất làm việc của developer. Việc không xác định được hay không xử lý được đoạn code gây ra nhiều rắc rối nhất sẽ là sai lầm tốn kém nhất mà team phát triển sản phầm gặp phải.

Đáng lưu ý trong khi đang cố gắng sửa bugs ở một đoạn code lỗi, có hơn 20% khả năng developer sẽ vô tình tạo thêm một bugs mới:

“Hầu hết các Modules bị lỗi rất phức tạp và khó hiểu đến mức không thể sửa được sau khi phát sinh”

Khi code rơi vào tình trạng tồi tệ này, nó cần được tái cấu trức để dễ hiểu và an toàn hơn khi xử lý hoặc cần một ai đó hiểu rõ họ đang làm gì viết lại code mới.

Không quá khó để phát hiện đoạn code lỗi nếu như một team cùng làm việc từ đầu. Tuy nhiên, đối với những team có sự thay đổi nhân sự thường xuyên,  bên cạnh việc diệt bugs, bạn sẽ cần theo dõi lịch sử bugs và các dữ liệu lỗi.

“80% thời gian để sửa 20% số bugs”

Có những bugs khó sửa hơn nhiều so với những bugs khác. Đôi lúc là do chất lượng code tồi hoặc bugs thực sự nghiêm trọng hơn so với đánh giá ban đầu. Hãy chuẩn bị đối mặt với những lúc ngay cả developers giỏi nhất của bạn cũng không thể ước tính khi nào bugs có thể sửa được.

80% sự thay đổi được tạo ra bởi 20% lượng code

Rất nhiều code được viết ra và không bao giờ thay đổi: giao diện đồng nhất và cố định, một số chức năng back office… Và có những code thay đổi liên tục: 20% số lượng các tính năng sử dụng trong 80% khoảng thời gian cần được điều chỉnh, sửa chữa cũng như thay đổi. Những đoạn code cốt lõi cần phải được tối ưu hóa và các code khác cần phải chỉnh sửa nhiều bởi chúng chứa một lượng bugs khá lớn.

Feathers đã chỉ ra rằng code thường xuyên bị thay đổi sẽ càng lớn dần theo thời gian. Kiểm tra lại các đoạn code có thể giúp tăng hiệu quả khi thay đổi cấu trúc code mà không quá khó để duy trì.

80:20 và thời gian lập trình

“80% số lượng code đầu tiên được hoàn thành bởi 20% thời gian, 20% nhiệm vụ còn lại tốn đến 80% thời gian”

Thông thường, không mất nhiều thời gian để đưa thứ gì đó đi vào hoạt động hoặc trông có vẻ như đang hoạt động , đặc biệt nếu bạn đang tạo ra kết quả đều đặn và nhanh chóng.

Tuy nhiên có rất nhiều việc cần phải hoàn thành ở phía sau để đề phòng và kiểm soát lỗi, đảm bảo hệ thống có thể vận hành tốt, tìm và sửa bugs, thu gọn code trước khi đưa vào vận hành. Quản lý dự án hay khách hàng thường không hiểu tại sao phải mất quá lâu để hoàn thành nốt 20% cuối cùng. Và programmer thường quên mất ước lượng phần thời gian này. Đây là lý do họ thường ước lượng sai, và prototyping có thể rất nguy hiểm khi đưa ra những mong đợi không thực tế.

80: 20 và quản lý phát triển phần mềm

Áp dụng nguyên tắc 80:20 có thể giúp bạn tiết kiệm tiền bạc và thời gian cũng như gia tăng cơ hội thành công, bằng cách tập trung vào những điều quan trọng: các tính tăng cốt lõi, những phần code thường xuyên chứa bugs nghiêm trọng, phần code thường xuyên thay đổi và cách sử dụng thời gian của nhóm.

Bài viết được dịch từ blog Dozen.com