Một người quản lí phần mềm viết cho tôi: “Chúng tôi muốn cải tiến chất lượng sản phẩm và muốn dùng phương pháp Six Sigma. Chúng tôi đã nhận được vài sách quảng cáo về phương pháp này từ các nhà tư vấn nhưng chúng tôi muốn kiểm xem nó làm việc tốt thế nào ở các công ti khác trước khi chi tiền. Xin thầy lời khuyên.”

Đáp: Six Sigma là cách tiếp cận hệ thống để cải tiến kết quả của quá trình chế tạo trong Motorola. Thuật ngữ này mô tả cho cách mô hình hoá thống kế chỉ ra năng suất chế tạo theo số phần trăm của sản phẩm không lỗi. Một qui trình Six Sigma có thể được mong đợi cho sản phẩm không lỗi tới 99.9%. Vào cuối những năm 1980, Motorola đặt mục đích về “Six Sigma” cho mọi hoạt động chế tạo của nó. Điều quan trọng cần lưu ý là đây là mục đích họ đặt ra, nó không có nghĩa mọi thứ họ xây dựng đều đã đạt tới mức chất lượng này như phần lớn mọi người thường nói tới. Mặc dầu Six Sigma là khái niệm rất tốt cho cải tiến qui trình trong chế tạo nhưng nhiều người thường “cứ nói” rằng họ đã đạt tới mức chất lượng này trong nhiều khu vực kể cả phần mềm.

Six Sigma bao gồm một vòng đời cải tiến có năm pha: Xác định vấn đề; Đo hiệu năng; Phân tích lỗ hổng giữa hiệu năng hiện thời và hiệu năng nhắm tới; Thực hiện cải tiến; và Kiểm soát qui trình (DMAIC). Và nhiều kĩ thuật phân tích thống kê để phân tích dữ liệu được thu thập trong pha đo như “Sơ đồ chạy”, “Phân tích căn nguyên”, “Kiểm soát giới hạn” v.v.

Về lí thuyết, nó là logic và dễ giải thích. Trong thực tế, thực hiện Six Sigma yêu cầu sự hỗ trợ mạnh của quản lí, nhiều đào tạo, và nhiều nỗ lực ngang qua mọi mức quản lí và công nhân. Dữ liệu được thu thập cho phân tích phải có chất lượng cao để nhận diện khu vực căn nguyên cho cải tiến. Chừng nào công ti còn chưa thiết lập tốt qui trình và có kỉ luật về văn hoá đo và sản phẩm phải có chất lượng tuyệt đối cao như trong y tế, quân sự, hay sản phẩm hạt nhân nơi độ chính xác và an toàn là mấu chốt, việc áp dụng Six Sigma có thể quá mạnh cho bất kì công ti nào và kết thúc trong thất bại.

Theo kinh nghiệm của tôi, xác định vấn đề là dễ nhưng thu thập dữ liệu và đo hiệu năng qui trình là không đơn giản. Phân tích kết quả có thể là vô nghĩa chừng nào bạn chưa có dữ liệu tuyệt đối chính xác và dữ liệu đủ ổn định mà có thể được định cỡ xuống độ chính xác nhất có thể được. Từ kinh nghiệm với CMMI, tôi nghĩ nếu công ti của bạn KHÔNG đạt tới ít nhất CMMI mức 5, Six Sigma không phải là cái gì đó bạn cần thử. Điều đó không có nghĩa là tôi không thích khái niệm về Six Sigma, tôi đã làm việc trên khái niệm đó trong nhiều năm khi tôi còn ở Motorola nhưng từ quan điểm thực hành, từng phương pháp có chỗ của nó, tôi tin Six Sigma là rất tốt trong chế tạo sản phẩm bán dẫn nơi cần phải không có lỗi nào. Tuy nhiên áp dụng khái niệm này cho phát triển phần mềm nơi các qui trình không được xác định rõ; việc thu thập dữ liệu chưa chín muồi; dữ liệu lịch sử không ổn định hay không đủ chính xác cho mô hình hoá thống kế có thể không phải là ý tưởng tốt.

Tôi không khuyên áp dụng Six Sigma trong phát triển phần mềm. Để cải tiến chất lượng, có những phương pháp tốt hơn được thiết kế cho phần mềm đã tồn tại như giám định chính thức (giám định Fagan), PSP, TSP v.v.

—-English version—-

Six Sigma

A software manager wrote to me: “We want to improve the quality of our products and want to use the Six Sigma method. We have received several brochures about this method from consultants but we want to check how well it works in other companies before spending our money. Please advice.”

Answer: Six Sigma is a systematic approach for improving the results of the manufacturing process in Motorola. The term describes a statistical modeling that indicates the manufacturing yield or the percentage of defect-free products. A Six Sigma process can be expected to yield 99.9% of defect free products. In the late 1980s, Motorola set a goal of “Six Sigma” for all of its manufacturing operations. It is important to note that this was the goal that they set, it does not means everything they built have achieve this level of quality as most people often referred to. Although Six Sigma is a very good concept for process improvement in the manufacturing but many people often “claimed” that they have achieved this level of quality in many areas including software.

Six Sigma consists of an improvement life cycle that has five phases: Define problem; Measure performance; Analyze gaps between current performance and target performance; Implement improvements; and Control the process (DMAIC). And several statistical analysis techniques to analyze data collected in the measure phase such as “Run charts”, “Root cause analysis”, “Control limits” etc.

In theory, it is logical and easy to explain. In reality, implementing Six Sigma requires a strong management support, a lot of trainings, and a lot of efforts across all level of management and workers. The collected data for analysis must be of high quality to identify root cause area for improvement. Unless the company has well established process and have disciplined measurement culture and the products must be of absolute high quality such as in medical, military, or nuclear products where accuracy and safety are critical, the application of Six Sigma can be overwhelming for any company and often end up in failure.

In my experience, defining the problem is easy but collecting data and measuring process performance are not that simple. The analysis of the results can be meaningless unless you have absolute accurate data and stable enough data that can be calibrated down to the most accuracy possible. From the experience with the CMMI, I think if your company has NOT reached at least CMMI level 5, Six Sigma is not something that you want to try. It does not mean I do not like the concept of Six Sigma, I worked on that for many years when I was at Motorola but from the practical point of view, each method has its place, I believe Sig Sigma is very good in the manufacturing of semi conducting products where a zero defect is needed. However applying this concept to software developments where processes are not well defined; data collection is not matured; historical data are not stable or accurate enough for statistical modeling may not be a good idea.

I do not recommend applying Six Sigma in software development. To improve quality, there are better methods designed for software already exist such as Formal inspection (Fagan’s inspection), PSP, TSP etc.