Đáp: Năm ngoái, tôi đã tham gia vào một nghiên cứu phần mềm dựa trên phân tích dữ liệu của 500 tổ chức phần mềm trên toàn thế giới. Sau đây là một số dữ liệu:

Tổ chức phần mềm tốt nhất về căn bản:

·        Khử bỏ trên 95% lỗi trước khi chuyển giao cho khách hàng

·        Ước lượng nhất quán trong phạm vi 10% chi phí và thời gian của dự án thực

·        Chi ít hơn 1% nỗ lực phát triển cho việc sửa lỗi

·        Đạt tới năng suất phát triển trên 25 điểm chức năng theo người tháng.

Tổ chức phần mềm hiệu năng tồi nhất:

·        Ước lượng ít hơn 50% số lỗi trước khi chuyển giao

·        Có các dự án thường vượt quá ước lượng đến hơn 50%

·        Dành hơn 30% nỗ lực phát triển cho việc sửa lỗi

·        Có năng suất phát triển thấp hơn 5 điểm chức năng cho mỗi người tháng.

Hỏi: Chúng tôi có kinh nghiệm rất xấu với một nhà tư vấn CMMI: Ông ấy tiến hành đánh giá kéo dài cả tháng trời và chẳng tạo ra cái gì ngoài một phát kiến là chúng tôi là CMMI mức 1. Việc lập kế hoạch hành động cải tiến cũng kéo dài tới nhiều tuần và chỉ chấm dứt khi chúng tôi hết tiền. Chúng tôi phải làm gì bây giờ?

Đáp: Dựa theo kinh nghiệm của tôi, việc đánh giá không nên kéo dài quá mười ngày. Kết quả điển hình nên là chi tiết về những điểm mạnh và điểm yếu của tổ chức của bạn chứ không chỉ là mức độ trưởng thành CMMI. Việc lập kế hoạch hành động cải tiến không nên kéo dài quá vài ngày và đến cuối bạn phải có một danh sách được xác định rõ về những nhiệm vụ cần thực hiện. Với tôi dường như là tổ chức của bạn đã bị lừa bởi “nhà tư vấn tự phong” người có thể không có tư cách, hầu như không được huấn luyện, và có lẽ đang dùng tổ chức của bạn như “nơi tập sự” cho kinh doanh tương lai. Sau đây là lời khuyên của tôi:

1)           Bao giờ cũng lựa người đánh giá hàng đầu được SEI uỷ quyền chứ không phải là “người đánh giá tự phong.” Bạn nên kiểm tra website của SEI về người đánh giá hàng đầu đủ tư cách.

2)           Đặt mục đích rõ ràng về cải tiến hội tụ vào hiệu năng của tổ chức như giảm chi phí, thời gian, tăng chất lượng và sự thoả mãn của khách hàng, KHÔNG PHẢI là mức trưởng thành CMMI.

3)           Phải chắc người của bạn hoàn toàn đồng ý với quan niệm về cải tiến qui trình trước việc đánh giá.

4)           Lựa chọn người giỏi nhất của bạn và đưa họ vào tổ đánh giá.

5)           Tuân theo qui trình đánh giá và dựa hầu hết vào dữ liệu được thu thập qua thực hành thực tế và KHÔNG dựa quá nhiều vào tài liệu.

6)           Chú ý tới vấn đề mấu chốt như trao đổi, sự tham gia của khách hàng;

7)           Thiết lập độ đo tuyến cơ sở để theo dõi tiến bộ;

8)           Điều phối các nhiệm vụ cải tiến tương ứng theo kế hoạch và làm hành động sửa chữa nghiêm chỉnh;

Hỏi: Chúng tôi là công ti phần mềm lớn với 8 đơn vị nghiệp vụ ở nhiều vị trí. Để cải tiến chúng tôi cần có đánh giá để xác định chúng tôi đang ở đâu theo mức CMMI. Chúng tôi có nên lập kế hoạch đánh giá toàn bộ công ti hay làm tách riêng từng đơn vị nghiệp vụ? Kết quả cho toàn thể công ti sẽ là gì?

Đáp: Đánh giá phần mềm bao giờ cũng tuỳ thuộc vào mục đích, mục tiêu, kích cỡ, ứng dụng, sản phẩm, và sự tham gia của khách hàng. Người đánh giá hàng đầu có kinh nghiệm bao giờ cũng hỏi những câu hỏi sau trước khi ra quyết định:

1)         Các nhóm nghiệp vụ này tạo ra chỉ một hay nhiều sản phẩm?

2)         Các nhóm nghiệp vụ này có tập trung vào phát triển, bảo trì hay vận hành phần mềm không?

3)         Tại sao bạn muốn cải tiến qui trình của mình bằng việc dùng CMMI?

4)         Các hoạt động cải tiến được tài trợ trực tiếp ở công ti hay ở từng vị trí nghiệp vụ?

5)         Có người quản lí cấp cao ngồi ngay ở từng vị trí không?

6)         Với phân tán địa lí, sẽ có khác biệt có thể trong nghiệp vụ và khách hàng, chúng là gì?

7)         Bạn đang tiến hành đánh giá để cải tiến qui trình hay để được mức trưởng thành CMMI?

8)         Có sức ép nào lên toàn công ti để phải ở mức độ trưởng thành nào đó vì lí do kinh doanh hay để thu được sự chú ý của cấp quản lí không?

Dựa trên kinh nghiệm của tôi, sẽ rất khó tiến hành đánh giá cho công ti lớn ở nhiều vị trí trên khắp nước. Tôi chuộng việc đánh giá cho từng vị trí một cách độc lập.  Kết quả cho toàn công ti có thể là như sau:

Nếu tất cả các nhóm nghiệp vụ đều được thẩm định ở CMMI mức 2, toàn bộ công ti cũng sẽ ở CMMI mức 2 theo mặc định do tổng của tất cả các bộ phận.

Nếu các nhóm nào đó đã được thẩm định ở CMMI mức 2 nhưng vài nhóm lại ở CMMI mức 1, thì công ti sẽ là ở CMMI mức 1, vì bạn không thể tuyên bố mức cho tất cả các nhóm dựa trên kết quả của vài nhóm.

Tuy nhiên, nếu bạn quyết định vẫn tiến hành việc đánh giá cho toàn công ti, bạn sẽ cần trả lời những câu hỏi sau:

1)         Nếu tôi có mỗi một mức CMMI cho toàn thể công ti, làm sao tôi có thể thảo luận kết quả với nhóm kinh doanh mà có thể được đánh giá ở mức cao hơn phần còn lại?

2)         Tôi cần bao nhiêu kế hoạch cải tiến? Chỉ một kế hoạch cho mọi nhóm hay 8 kế hoạch tách rời cho từng nhóm?

3)         Làm sao tôi biết rằng tôi có đủ dữ liệu để đề cập tới vấn đề cho từng nhóm? Tôi có thể bắt được điểm mạnh và điểm yếu cho từng nhóm ở vị trí khác nhau được không?

4)         Làm sao tôi xử trí được một nhóm có nhiều điểm mạnh và vài điểm yếu khi các nhóm khác không có những điểm đó? Nhóm không có điểm yếu nào thì sao, khi nhóm khác lại có nhiều?

Dựa trên kinh nghiệm của tôi, vấn đề gai góc nhất trong tiến hành đánh giá CMMI bao gồm:

1)     Phân tích tổ chức để xác định phạm vi của đánh giá

2)     Lấy mẫu dự án (tức là dự án đại diện là gì? bao nhiêu dự án được cần trong việc đánh giá?)

3)     “Ngoại lệ” là gì mà cần được xem xét kĩ lưỡng liên quan tới tác động của chúng lên qui trình và năng lực của tổ chức?

Đây là một ví dụ về tình huống thực đã xảy ra trong vài năm trước:

Một tổ chức lớn muốn làm một thẩm định về một miềm rất rộng các nhóm phần mềm và ứng dụng. Họ kiếm được cái họ cần: Mức độ trưởng thành CMMI nhưng họ lại không hài lòng với kết quả. Lí do là vì sự đa dạng trong các qui trình xuyên qua các nhóm, nơi mà những điểm mạnh và điểm yếu không được phân bố đúng. Tổ chức tiếp đó đã mất nhiều tháng sau thẩm định để sắp xếp từng phát kiến, để xác định phần nào của tổ chức cần được đề cập tới phát kiến nào và chẳng ai thấy hài lòng. Đến cuối họ dừng hoạt động cải tiến bởi vì nó tiêu tốn quá nhiều nỗ lực.

Kết luận của tôi:  Hợp nhất kết quả qua những miền đa dạng dẫn tới dữ liệu KÉM ý nghĩa và việc cải tiến qui trình KÉM hiệu quả.

Hỏi: Tại sao người kĩ sư phần mềm tiếp tục đi theo kế hoạch không hợp lí, dựa trên lịch biểu phi hiện thực do cấp quản lí ép xuống?

Đáp: Trong hầu hết các tổ chức, người kĩ sư phần mềm thường phải chịu sức ép theo cam kết lịch biểu vì nhiều người quản lí tin rằng sức ép lớn bao giờ cũng được cần tới để làm cho các kĩ sư sản xuất. Chừng nào mà tổ chức còn chưa có dữ liệu lịch sử và dùng chúng cho ước lượng của họ, chẳng ai biết được liệu lịch biểu là hợp lí hay không.  Nhiều người quản lí muốn thấy cách kĩ sư phản ứng với bản kế hoạch và lịch biểu dự án phi thực tế. Nếu bạn không có dữ liệu lịch sử để thách thức nó, bạn bao giờ cũng bị mắc kẹt với nó. Lời khuyên của tôi là thu thập và dùng dữ liệu lịch sử bất kì khi nào bạn có thể.

Hỏi: Tại sao kiểm điểm và giám định phần mềm lại không được dùng hầu khắp khi mà chúng có thể cải tiến hiệu năng dự án một cách có ý nghĩa?

Đáp: Mục đích của kiểm điểm và giám định phần mềm là để phát hiện và sửa khiếm khuyết trước khi chúng rò rỉ sang các pha phát triển kế tiếp vào vào sản phẩm cuối. Tuy nhiên, việc chấp thuận kĩ thuật này đã bị chậm lại do những điều sau:

1)          Nhiều người quản lí thấy chi phí phụ thêm của kiểm điểm, không thấy ích lợi của việc giảm đáng kể khiếm khuyết và việc làm lại.

2)          Nhiều người hành nghề đã đối diện với lịch biểu chặt đều ngần ngại làm việc phụ thêm.

3)          Người hành nghề nào đó bận tâm rằng việc phát hiện công khai các khiếm khuyết trong công việc của họ có thể ảnh hưởng tới hiệu năng của họ.

4)          Kiểm điểm và giám định phần mềm yêu cầu huấn luyện đúng do đó nó cũng làm gia tăng chi phí của tổ chức phần mềm.

Hỏi: Tại sao chúng tôi cần tập trung vào sự thoả mãn của khách hàng? Chúng tôi đã đạt tới CMMI mức 5 rồi.

Đáp: Một công ti có thể là ở CMMI mức 5 khi làm ‘áo mưa giấy.” Họ có thể có qui trình tốt nhất để làm áo mưa giấy với chất lượng cao. Nhưng nó tốt thế nào nếu trời mưa? Bạn có cho rằng khách hàng muốn áo mưa giấy không? Sự thoả mãn của khách hàng là mục đích của doanh nghiệp và phải là trung tâm của bất kì chương trình cải tiến chất lượng nào.

Hỏi: Nếu phần mềm không trưởng thành như khoa học thì thuê nghệ sĩ phần mềm giỏi nhất là cách chọn tốt hơn là đầu tư hàng triệu đô la vào cải tiến qui trình. Thầy nghĩ sao?

Đáp: Tôi không tin nghệ sĩ phần mềm có thể làm công việc tốt hơn là tổ kĩ sư phần mềm. Nhiều người tưởng rằng các nghệ sĩ biết một cách trực giác về cách làm công việc phần mềm, cho nên sẽ chẳng cần việc cải tiến qui củ. Nếu điều này đúng thì người ta sẽ trông đợi bất kì công ti nào thuê được nghệ sĩ giỏi nhất sẽ không bao giờ phải chịu sa sút bởi các vấn đề phần mềm chung như chất lượng, năng suất và hiệu năng lịch biểu v.v. Điều này vẫn còn xa với chân lí vì các vấn đề phần mềm vẫn là vấn đề then chốt trong công nghiệp ngày nay. 

Nếu nghệ sĩ phần mềm là giải pháp thì họ tới từ đâu? Chúng ta có được họ từ đâu? Làm sao chúng ta phân biệt được “nghệ sĩ thực” với người giả mạo? Làm sao nghệ sĩ có thể sống được trong môi trường mà khách hàng thường xuyên thay đổi yêu cầu tới ba bốn lần trong một tuần? Tôi tin thuê người giỏi nhất là sống còn nhưng điều bản chất là hỗ trợ họ bằng qui trình phần mềm hiệu quả.

Hỏi: Tại sao phần mềm lại cứ đắt thêm thế, và lại quá chậm để đưa ra tính năng mới?

Đáp: Phần lớn các tổ chức phần mềm đều dành quá nửa nỗ lực của họ vào việc làm lại và phần còn lại dành cho phát triển các chức năng mới. Bởi vì việc hỗ trợ sản phẩm đã có trong tay khách hàng có ưu tiên cao hơn việc phát triển mới, việc chữa lỗi cho khách hàng, những điều rất tốn kém về nỗ lực (tức là chi phí) bao giờ cũng can nhiễu vào việc đưa ra sản phẩm mới (tính năng mới).

English version

CMMI-11

Question: What is the different between the best software organization and the worst? Do we have any data?

Answer: Last year, I have participated in a software research based on the data analysis of 500 software organizations worldwide. Following are some data:

The best software organizations typically:

·        Eliminate over 95% of defects before delivery to customers

·        Estimate consistently to within 10% of the actual project’s cost and time

·        Spend less than 1% of the development effort on defect correction

·        Achieve development productivity above 25 function points per person month.

The lowest performing software organizations:

·        Eliminate less than 50% of defects before delivery

·        Have projects which often exceed estimates by more than 50%

·        Spend more than 30% of the development effort on defect correction

·        Have development productivity below 5 function points per person month.

Question: We had very bad experience with a CMMI consultant: He conducted an appraisal that lasted more than a month and produced nothing but a finding stated that we are a CMMI level 1. The improvement action planning also lasted on to several weeks and only stopped when we ran out of money. What should we do now?

Answer: Based on my experiences, an appraisal should not last more than ten days. A typical result should detail your organization’s strengths and weaknesses not only a CMMI maturity level. An improvement action planning should not last more than few days and by the end you should have a well defined list of improvement tasks to execute. It seems to me that your organization was cheated by a “Self-declared consultant” who may be unqualified, have little training, and probably using your organization as a “learning place” for future business. Following are my advices:

1)               Always select an SEI authorized lead appraiser not any “self- declared appraiser” You should check the SEI website for qualified Lead appraiser.

2)               Set clear goals for the improvement that focus on organizational performance such as reduce cost, time, increase quality and customer satisfaction, NOT a CMMI maturity level.

3)               Make sure your people completely agree to the concept of process improvement before an appraisal.

4)               Select your best people and put them in the appraisal team.

5)               Follow the appraisal process and rely mostly on data collected via actual practices and NOT too much on documentation.

6)               Pay attention to the critical issues such as communication, customer involvement;

7)               Establish baseline measurement to track progress;

8)               Monitor improvement tasks according to the plan and take corrective action seriously;

Question: We are a large software company with 8 business units located in several cities. For improvement we need to have an appraisal to determine where we are in the CMMI level. Should we plan to appraise the entire company or each business unit separately? What would be the result for the entire company?

Answer: Software appraisal always depends on the goals, objectives, size, applications, products, and customer involvement. An experienced lead appraiser always asks the following questions before making a decision:

1)         Are these business groups producing just one product or many?

2)         Are these business groups focusing on software development, maintenance or operation?

3)         Why do you want to improve your process using CMMI?

4)         Are improvement activities directly funded at the company or at each business site?

5)         Is there key senior manager physically located at each site?

6)         For geographical dispersion, there would be possible differences in business and customers, what are they?

7)         Are you conducting appraisal for process improvement or to get a CMMI maturity level?

8)         Is there a pressure for the entire company to be at certain maturity level for business reason or to get management attention?

Based on my experience, it would be very difficult to conduct one appraisal for a large company with multiple sites located around the country. I would prefer to appraise each site independently.  The result for the entire company could be as follow:

If all business groups were assessed at CMMI level 2, the entire company would also be a CMMI level 2 by default due to the sum of all the parts.

If some groups were assessed at CMMI level 2 but few were at CMMI level 1, then the company would be a CMMI level 1, since you can not claim level for all groups based on results of some.

However, if you decide to conduct just one appraisal for the entire company you will need to answer the following questions:

1)          If I have a single CMMI level for my entire company, how could I discuss the result with a business group that could be appraised at higher level than the rest?

2)          How many improvement plans do I need? Just one plan for all groups or 8 separate plans for each?

3)          How do I know that I have enough data to address issues for each group? Could I come up with strengths and weaknesses for each group at different site?

4)          How do I handle a group that has much strength and few weaknesses when other groups do not? What about a group that do not have any weaknesses when another group has a lot?

Based on my experience, the toughest issues in conducting a CMMI appraisal include:

1)     Organizational analysis to determine the scope of an appraisal

2)     Project sampling (i.e. what is a representative project? how many projects are needed in an appraisal?

3)     What are the “exceptions to the rule” that need to be thoughtfully considered regarding their impact on process and organizational capability?

Here is an example of a real situation happened few years ago:

A large organization wanted to do just one assessment over a very broad range of software groups and applications. They got what they wanted: A CMMI maturity level but they were not happy with the results. The reason was due to the diversity in processes across the groups where strengths and weaknesses were not distributed correctly. The organization subsequently spent many months after the assessment to sort through each of the findings to determine what portions of the organization needed to address what findings and still no one were happy. In the end they stopped the improvement activity because it consumed so much efforts.

My conclusion:  Consolidating results across diverse areas leads to LESS meaningful data and LESS effective process improvement.

Question: Why software engineer continue to follow an unreasonable plan, based on unrealistic schedule dictated by management?

Answer: In most organizations, software engineers are often pressured into schedule commitments since many managers believe that heavy pressure is always required to make engineers produce. Unless the organization has historical data and uses them for their estimates, no one will know if the schedule is reasonable or not.  Many managers like to see how engineer react to a unreasonable project plan and schedule. If you do not have historical data to challenge it, you always stuck with it. My advice is to collect and use historical data whenever you can.

Question: Why software reviews and inspections are not used extensively when they could improve project performance significantly?

Answer: The purpose of software reviews and inspections is to detect and correct defects before they leak through subsequent development phases and into the end-products. However, the adoption of this technique has been slow due to the following:

1) Many managers see the added cost of reviews, not the benefits of greatly reduced defects and reworks.

2) Many practitioners already faced a tight schedules are reluctant to take on additional work.

3) Some practitioner were concerned that publicly detecting defects in their own work may affect their performance

4) Software reviews and inspections require proper training therefore it also added to the cost of software organization.

Question: Why do we need to focus on customer satisfaction? We already achieved CMMI level 5.

Answer: A company could be CMMI level 5 when making “paper rain coats”. They may have the best process to make paper rain coats of highest quality. But what good is it if it rain? Do you think customers want paper rain coats? Customer satisfaction is the goal of business and should be the heart of any quality improvement program.

Question: If software is not mature as a science then hiring the best artist is a better choice than investing million dollars to process improvement. What do you think?

Answer: I do not believe a few software artists can do better work than a team of software engineer. Many people think that artists know intuitively how to do software work, so no orderly improvement will be needed. If this is true than one would expect any company who hire the best artists would never suffer from common software problems such as quality, productivity, and schedule performance etc. This is far from the truth since software problems are still key issues in industry today.  If software artist is the solution then where are they coming from? Where do we get them? How do we distinguish a “real artist” from the fake one? How could an artist last in an environment where customer keeps changing requirements three or four times a week? I believe hiring the best people is vital but it is also essential to support them with an effective software process.

Question: Why software is getting more expensive, and too slow to come up with new feature?

Answer: Most software organizations spend more than half of their effort on rework and the remainder on developing new functions. Because supporting products that are already in the customers hands takes priority over new development, fixing customer defects, which is very expensive in effort (i.e. Cost) always interferes with the release of new products (new features).