Hỏi: Chúng tôi đã được một số nhà tư vấn tiếp cận tới đề nghị tăng tốc thành tựu mức CMMI của chúng tôi bằng việc cung cấp bộ mẫu và huấn luyện về cách dùng các bộ mẫu này để thoả mãn các mục đích trưởng thành CMMI ở từng mức. Họ đảm bảo rằng chúng tôi có thể thu được mức CMM cao trong thời gian rất ngắn như vài tháng cho tới một năm. Thầy nghĩ gì?

Đáp: Điều dường như hiển nhiên với tôi là những nhà tư vấn đó chỉ có mục đích duy nhất là làm tiền từ tổ chức muốn đạt tới mức CMMI mà không làm gì để cải tiến năng suất, chất lượng của họ và giảm chi phí. Tôi không biết những bộ mẫu “ăn liền” này tốt đến đâu. (Có lẽ tương tự với chất lượng của mì ăn liền.) Nhưng liệu có thể làm cho một tổ chức tuân theo một tập các tài liệu không quen thuộc, không liên quan tới tổ chức, vẫn đạt tới thành công không? Điều đó có nghĩa gì cho kinh doanh của tổ chức của bạn?

Lời đảm bảo đạt tới mức CMMI trong thời gian rất ngắn nhắc nhở tôi về quảng cáo trong một tờ báo địa phương: “Đảm bảo mất 40 kilô trong hai tuần.” Tôi không biết bao nhiêu người mua cái “công thức phép màu” đó nhưng mất but losing 40 kilo trong hai tuần là không thể được và dứt khoát rủi ro cho sức khoẻ. Đạt tới mức trưởng thành cao trong vòng vài tháng là quá tốt không thể đúng được. Lần sau bạn gặp những nhà tư vấn đó bạn nên yêu cầu họ cung cấp cho bạn những thông tin sau:

1.     Bao nhiêu tổ chức đã tăng tốc cải tiến qui trình bằng việc dùng những bộ mẫu này? Họ là ai? Họ có cho bạn tên tuổi của họ để liên hệ kiểm chứng về “bộ mẫu” để chắc nó có tác dụng như quảng cáo không?

2.     Liệu có tổ chức như vậy – tổ chức đổi rất nhanh bằng việc mua bộ mẫu từ những nhà tư vấn này – bạn có thể muốn biết kinh doanh của họ tốt thế nào. Họ có làm nhiều tiền không, có đạt tới sự thoả mãn khách hàng tốt hơn không hay xây dựng sản phẩm tốt hơn không?

3.     Bạn có thể muốn biết bộ mẫu đã làm cho tổ chức của họ cải tiến được bao nhiêu. Chất lượng có tốt hơn không? Ước lượng lịch biểu có cải tiến không? Hãy hỏi họ dữ liệu về cải tiến.

Nếu mục đích duy nhất của bạn là đạt tới CMMI mức 5 mà không cần nỗ lực gì thì tôi nghĩ bạn nên tự mình in ra cho mình một chứng chỉ tuyên bố rằng tổ chức của bạn là CMMI mức 5 chẳng cần bận tâm mua bộ mẫu hay tiến hành đánh giá vì chi phí in một mảnh giấy rẻ hơn nhiều việc thuê tư vấn. Lời khuyên của tôi là: Tiết kiệm tiền của bạn.

Hỏi: Tại sao chúng tôi cần cải tiến phần mềm? Vấn đề với phần mềm là gì?

Đáp: Theo báo cáo cho chính phủ Mĩ, phần lớn trong số $250 tỉ đô la chi cho phát triển phần mềm hàng năm của Mĩ bị phí hoài, chậm trễ, không đầy đủ, hay bị tiêu vài các dự án bị cắt bỏ. Chỉ 16% ($40 tỉ) về dự án phần mềm được hoàn thành trong ngân sách, đúng thời gian, và chứa mọi chức năng. 53% ($132.5 tỉ) về dự án phần mềm bị coi là quá ngân sách, chậm trễ, và với ít chức năng hơn được lên kế hoạch. 31% ($77.5 tỉ) về dự án phần mềm bị coi là hư hỏng và phải bị cắt bỏ.

Nếu bạn không thấy vấn đề gì về cách bạn làm phần mềm, có lẽ các dự án phần mềm của bạn bao giờ cũng trong ngân sách, đúng thời gian, và với mọi chức năng được hoàn thành. Bạn có thể không cần cải tiến nhưng người khác cần cải tiến.

 

Hỏi: Tổ chức của tôi có nhiều vấn đề với sản phẩm phần mềm. Chúng tôi biết rằng chúng tôi là tổ chức CMMI mức 1. Là người quản lí, tôi muốn cải tiến và mọi người của tôi gợi ý rằng chúng tôi bắt đầu với Miền qui trình quản lí yêu cầu. Tôi nên làm điều này hay tôi nên bắt đầu với điều khác?

Đáp: Nếu bạn muốn bắt đầu với Quản lí yêu cầu bạn có thể muốn xem xét việc cải tiến qui trình thu thập yêu cầu và khử bỏ lỗi trong pha yêu cầu. Vấn đề chính trong miền này là:

1.      Thiếu cái vào của người dùng cuối. Khách hàng không có thời gian tham gia vào hay nói cho bạn điều họ cần.

2.      Các yêu cầu và đặc tả không đầy đủ.

3.      Thay đổi thường xuyên trong đặc tả yêu cầu.

Dữ liệu công nghiệp đã chỉ ra một cách lặp lại rằng việc khử bỏ lỗi trong pha yêu cầu làm giảm chi phí phần mềm tới 150 lần ít hơn chi phí cho việc sửa khiếm khuyết ở các pha sau trong dự án. Điều rõ ràng là một qui trình quản lí yêu cầu hiệu quả là then chốt để chuyển giao phần mềm chất lượng cao cho khách hàng của bạn. Bằng việc cải tiến miền này, bạn đang đi đúng đường đấy.

Hỏi: Quản lí yêu cầu ở mức 2 của CMMI có giúp thu được yêu cầu tốt hơn hay dừng thay đổi yêu cầu không?

Đáp: Quản lí yêu cầu KHÔNG về cách thu được yêu cầu mà thay vì thế về điều bạn cần quản lí yêu vì chúng bao giờ cũng thay đổi.

Có 3 kĩ thuật để thu được yêu cầu tốt hơn:

1.      Hỏi tại sao một yêu cầu đã nêu lại tồn tại và ai là người dùng?

2.      Áp dụng kĩ thuật có tên “FURPS+”

3.      Nhìn vào nhóm các yêu cầu “4 E”.

• Nhận diện người dùng giúp xác định chỗ tìm các yêu cầu và ai cần thương lượng về yêu cầu đã nêu và thiết lập qui trình trao đổi tốt hơn và dùng kĩ thuật bản mẫu để thu được yêu cầu tốt hơn và giảm số những thay đổi yêu cầu. Tuy nhiên, đôi khi cũng khó nhận diện nguồn thực của yêu cầu.
• Cách tiếp cận “FURPS+” nhận diện ‘siêu phân loại’ bên trong các yêu cầu có thể được gộp nhóm. Chúng là:
• Chức năng (tập tính năng, năng lực, tính tổng quát, an ninh).
• Tính dùng được (nhân tố con người, thẩm mĩ, nhất quán, tài liệu).
• Tính tin cậy (tần xuất/độ nghiêm trọng của hỏng hóc, tính phục hồi được, tính tiên đoán được, độ chính xác, thời gian trung bình hỏng).
• Hiệu năng (tốc độ, tính hiệu quả, tiêu thụ tài nguyên, thông lượng, thời gian đáp ứng).
• Tính hỗ trợ (tính kiểm thử được, tính mở rộng được, tính thích ứng được, tính bảo trì được, tính tương hợp, tính cấu hình được, tính phục vụ được, tính cài đặt được, tính bản địa hoá được)

Có thể còn có phân loại khác về các ràng buộc tổ chức như chi phí, lịch biểu, giới hạn cán bộ, huấn luyện và tập kĩ năng, và tính tương hỗ với các dự án khác.

·        Cách tiếp cận “4 E về yêu cầu ” giải quyết với 4 gộp nhóm các yêu cầu:

·        Explicit – Tường minh

·        Expected – Mong đợi

·        Elusive – Khó nắm bắt

·        Exciting – Lí thú

Đây là 3 kịch bản ví dụ khác để chỉ ra cách “4 E” có các mức rủi ro khác nhau tuỳ theo kịch bản.

1.      Một sản phẩm mới trong thị trường mới sẽ có tất cả các E ở mức rủi ro cao ngoại trừ Mong đợi, vì nó là thị trường mới.

2.      Một sản phẩm mới trong thị trường hiện có sẽ có các yêu cầu Tường minh và Lí thú trong phân loại rủi ro thấp, nhưng cả hai Mong đợi và Lí thú sẽ có kiểu rủi ro cao.

3.      Cuối cùng, một sản phẩm cải biên sẽ có yêu cầu Mong đợi cao, và thậm chí sẽ có yêu cầu Mong đợi cao hơn đối với tổ chức được xếp ở SEI mức 1 so với mức 2.

Hỏi: Tại sao hoạt động cải tiến phải được đo?

Đáp: Tôi không biết cách giải quyết hiệu quả với tiến bộ thực nếu không đề cập tới việc đo. Phần lớn mọi người đều không có vấn đề khi dùng việc đo để thu được hiểu biết về nhiều điều trong cuộc sống của họ – Chỉ số thị trường chứng khoán, trọng lượng của họ so với thực đơn hàng ngày v.v – nhưng họ vẫn không thoải mái khi dùng số để mô tả trạng thái hoạt động riêng của họ, hay trạng thái của dự án mà họ đang làm việc. Ngày nay, người quản lí phần mềm thường đo lịch biểu hay nỗ lực, nhưng không mấy tập trung vào chi phí, kích cỡ sản phẩm hay khiếm khuyết.

Tôi tin người quản lí phần mềm giỏi sẽ đo kích cỡ, chi phí, thời gian, và khiếm khuyết để quản lí dự án một cách hiệu quả. Họ cần điều phối kích cỡ và khiếm khuyết tại từng pha trong vòng đời phần mềm và có hành động sửa chữa tương ứng. Tôi tin đó là điều mấu chốt rằng người quản lí dự án nhìn vào nhiều cách đo (chỉ báo) như khả năng đảm bảo bức tranh đầy đru. Người phi công có sung sướng khi cho chiếc máy bay bay mà chỉ có một đồng hồ và máy đo nhiên liệu để hướng dẫn họ không? Tôi tin rằng điều này cũng tương tự với một dự án phần mềm được theo dõi chỉ bằng quan sát chi phí và cột mốc.

 

Hỏi: CMMI phổ biến thế nào ở châu Á?

Đáp: CMMI rất phổ biến trong cộng đồng kĩ nghệ phần mềm trên khắp thế giới. Trong vài năm qua, đã có nhiều hội nghị ở châu Á tổ chức các hội thảo về cải tiến qui trình phần mềm bằng việc dùng CMMI. Từng cuộc hội nghị đều thu hút vài nghìn người dự. Mạng cải tiến qui trình phần mềm Software Process Improvement Networks (SPIN) – nhóm gặp gỡ và chia sẻ kinh nghiệm trong các hoạt động cải tiến phần mềm đang được thiết lập trên khắp thế giới. Với thống kê mới nhất, có 40 nhóm SPIN tích cực ở châu Á và nhiều nhóm nữa đang nổi lên. Cải tiến qui trình bao gồm không chỉ vấn đề kĩ thuật và quản lí, mà còn đa dạng các nhân tố văn hoá và xã hội. Sự phổ biến của CMMI ở châu Á có lẽ là do khả năng của nó tổ hợp các nhân tố này và làm việc rất tốt.

 

Hỏi: Nguồn của rủi ro phần mềm là gì? Tại sao mọi người không thích nói về nó?

Đáp: Quản lí rủi ro là quản lí dự án đối với người quản lí phần mềm có kinh nghiệm. Nó là về nhìn trước điều có thể xảy ra và chuẩn bị giải quyết nó.

Rủi ro có ba yếu tố, xác suất, tác động và chọn lựa. Phần lớn việc quản lí rủi ro được mô tả trong văn đàn chỉ với xác suất và tác động. Các nguồn của ruiro bao gồm văn hoá, tài chính, kĩ thuật, và môi trường. Sự tập trung của rủi ro thường vào kĩ thuật nhưng kĩ thuật bị ảnh hưởng bởi các nguồn khác cho nên nhiều nguồn bao giờ cũng hiện diện trong hầu hết mọi rủi ro. Hành vi cá nhân, nhóm, tổ chức và văn hoá ảnh hưởng tới việc dung thứ rủi ro của chúng ta và cách thức rủi ro được đề cập và cảm nhận.

Lí do mọi người không thích nói về rủi ro là họ không hiểu hay không biết cách dự đoán và giải quyết nó khi nó tới.

 

Hỏi: Dường như với tôi việc tập trung chính vào kiểm điểm phần mềm là cái gì đó được thực hiện dễ dàng thế và điều đó hiệu quả trong việc loại bỏ khiếm khuyết. Thầy nghĩ gì?

Đáp: Kiểm điểm phần mềm là một trong những kĩ thuật tốt nhất để nhận diện và loại bỏ khiếm khuyết và nên được nhấn mạnh. Tuy nhiên, khi ước lượng lịch biểu không được xác định tốt, thời gian trở thành gay cấn, người kĩ sư phần mềm thường được bảo nhảy qua kiểm điểm và gửi đi sản phẩm, bất kể số khiếm khuyết. Do đó,  điều quan trọng là cải tiến lập lịch trước khi hội tụ vào kiểm điểm. Điều này không có nghĩa là kiểm điểm nên bị nhảy qua, thay vì chúng có thể không hiệu quả chừng nào ước lượng lịch biểu còn chưa được cải tiến. Kiểm điểm ngang quyền hiệu quả đòi hỏi rằng bạn lập kế hoạch kiểm điểm, huấn luyện mọi người tiến hành chúng, và theo dõi để đảm bảo chúng được tiến hành tương ứng và những hoạt động này có thể được thực hiện khi bạn có đủ thời gian.

 

Hỏi: Người quản lí của tôi muốn có dữ liệu chứng minh rằng cải tiến qui trình thực sự đáng trả giá. Dữ liệu trả giá là gì và làm sao có chúng?

Đáp: Dữ liệu trả giá bao giờ cũng được cần tới bởi vì người quản lí cần chúng để biện minh cho đầu tư vào cái gì đó mới như cải tiến qui trình. Vì tổ chức của bạn có thể chưa có những dữ liệu đó, tôi khuyến cáo bạn dùng dữ liệu từ các nguồn ngoài cho tới khi các kết quả nội bộ có ý nguiax có thể được chứng minh. Dữ liệu trả giá là phần thưởng/kết quả/ích lợi để làm việc cải tiến qui trình, thường được diễn đạt dưới dạng định lượng (tức là đô la). Việc trả giá có thể được làm tài liệu theo mô hình thu hồi vốn đầu tư return-on-investment (ROI) – chi phí thực hiện cải tiến qui trình so với tiết kiệm nảy sinh từ cải tiến qui trình. Có nhiều dữ liệu cải tiến đã được công bố trong công nghiệp và bạn có thể lên internet và tìm chúng.

—-English version—-

 

CMMI-14

Question: We have been approached by number of consultants offering to accelerate our CMMI level achievement by providing example kits and training in how to use these kits to satisfy the CMMI maturity goals at each level. They guarantee that we can get to high CMM level in very short time such as few months to a year. What do you think?

Answer: It seems obvious to me that these consultants only goal is making money from organization that want to achieve a CMMI level without doing anything to improve their productivity, quality, and reducing cost. I do not know how good these “instant” example kits are. (Probably similar to the quality of instant noodles) But is it possible for an organization to follow an unfamiliar set of documents, unrelated to your organization, and achieve success? What meaning would that have for the business of your organization?

The guarantee to achieve a CMMI level in a very short time reminds me of the advertising in local newspaper: “Lose 40 kilos in two weeks guaranteed”. I don’t know how many people buy that “Miracle formula” but losing 40 kilo in two weeks is impossible and definitely a health risk. Reaching a high maturity level within a few months is too good to be true. The next time you see these consultants you should ask them to provide you with the following information:

1.     How many organizations have accelerated process improvement using these kits? Who are they? Will they give you their names to contact for verification of the “instant kits” to make sure it works as advertise?

2.     If there is such an organization—one that moved very quickly by buying kits from these consultants —you may want to know how well their business was. Did they making more money, achieve better customer satisfaction or building better product?

3.     You may want to know how much improvement has the kit made in their organization. Is quality getting better? Is schedule estimate improving? Ask them for improvement data.

If your only goal is to achieve a CMMI level 5 without any efforts than I think you should  print yourself a certificate declare that your organization is a CMMI level 5 without bother to buy a kit or conduct an appraisal since the cost of printing a piece of paper is far cheaper than hiring a consultant. My advice: Save your money.

 

Question: Why do we need to improve software? What are the problems with software?

Answer: According to a U.S government report, much of the $250 billion in annual U.S. software development spending is wasted, late, incomplete, or spent on canceled projects. Only 16% ($40 billion) of software projects are completed within budget, on time, and with all functions included. 53% ($132.5 billion) of software projects are considered over budget, delayed, and with fewer functions than planned. 31% ($77.5 Billion) of software projects are considered impaired and have to be canceled.

If you do not see any problem with the way you do software, perhaps your software projects are always within budget, on time, and with all the functions completed. You may not need to improve but others do.

 

Question: My organization has a lot of problems with our software products. We know that we are a CMMI Level 1 organization. As a manager, I want to improve and my people suggested that we start with the Requirement Management Process Area. Should I do this or should I start with other?

Answer: If you want to start with Requirements Management you may want to consider improving the requirement gathering process and eliminating errors in the requirements phase. The major problems in this area are:

1.      Lack of end-user input. Customer does not have time to participate or tell you what they need.

2.      Incomplete requirements and specifications.

3.      Frequent change in requirements specifications.

Industry data has repeatedly shown that eliminating errors in the requirements phase can reduce software cost to about 150 times less than the cost of repairing the defect at later phases in the project. It is clear that an effective RM process is the key to delivering high quality software to your customers. By improving this area, you are on the right track.

 

Question: Does the Requirements Management in the level 2 of CMMI help you to obtain better requirements or stop requirements changes?

Answer: Requirements Management is NOT about how to obtain requirements but rather what you need to manage requirements since they are always changing.

There are 3 techniques of obtain better requirements:

1.      Ask why a given requirement exists and who are the users?

2.      Apply a technique called “FURPS+”

3.      Look at the “4 E’s” grouping of requirements.

• Identifying user helps to determine where to look for requirements and whom to negotiate with for a given requirement and establish a better communication process and prototype technique to get better requirements and reduce the number of requirements changes. However, sometimes it is difficult to identify the real source of a requirement.
• The “FURPS+” approach identifies the ‘meta categories’ within which requirements could be grouped. They are:
• Functionality (feature set, capabilities, generalities, security).
• Usability (human factors, aesthetics, consistency, documentation).
• Reliability (frequency/severity of failure, recoverability, predictability, accuracy, mean time to failure).
• Performance (speed, efficiency, resource consumption, through-put, response time).
• Supportability (testability, extensibility, adaptability, maintainability, compatibility, configurability, serviceability, instability, localizability)
• There maybe yet another category for organizational constraints such as cost, schedule, staff limits, training and skill sets, and interdependency with other projects.
• The “4 E’s of Requirements” approach deals with 4 groupings of requirements:
  • Explicit
  • Expected
  • Elusive
  • Exciting

Here are 3 different example scenarios to show how the “4 E’s” would have different risk levels depending on the scenario.

1.      A new product in a new market would have all the E’s at a high risk level except Expected, since it was a new market.

2.      A new product in an existing market would have Explicit and Exciting requirements in the low risk category, but both Expected and Elusive would be high risk types.

3.      Finally, a revised product would have high Expected requirements, and there would be even higher Expected requirements for an organization rated as SEI Level 1 vs. Level 2.

 

Question: Why improvement activities have to be measured?

Answer: I do not know how to effectively deal with real improvement without addressing measurement. Most people have no problem using measurements to gain understanding of many things in their lives—the Stock market Index, their weight on a diet  etc.— but they are still uncomfortable using numbers to describe the status of their own activities, or the status of a project on which they are working. Today, software managers often measure schedule or effort, but not much focus on cost, product size or defects.

I believe a good software manager should measure size, cost, time, and defects to manage a project effectively. They need to monitor size and defect at each phase in the software life cycle and take corrective actions accordingly. I believe it is critical that a project manager look at as many measurements (indicators) as possible to insure a complete picture. Would a pilot be happy flying an airplane with only a clock and a fuel gauge to guide them? I believe that this is analogous to a software project being tracked by only watching cost and milestones.

 

Question: How popular is the CMMI in Asia?

Answer: The CMMI is very popular in software engineering communities all over the world. In the past few years, there have been several conferences in Asia that held workshops in software process improvement using CMMI. Each of the conference draws several thousand attendees. The Software Process Improvement Networks (SPIN) a group that meet and share experiences in software improvement activities is being established all over the world. At the last count, there are 40 active SPIN group in Asia with more are emerging. Process improvement includes not only technical and managerial issues, but also a variety of cultural and sociological factors. The popularity of CMMI in Asia is probably due to its ability to incorporate these factors and work very well.

 

Question: What is the source of software risk? Why people do not like to talk about it?

Answer: Risk Management is project management for experienced software manager. It is about anticipate what may happen and prepare to deal with it.

Risk has three elements, probability, impact, and choice. Most risk management described in the literature deals only with probability and impact. Sources of risk include cultural, financial, technical, and environmental. The focus of risk is usually on the technical but the technical is influenced by other sources so multiple sources will always be present in almost every risk. Individual, group, organizational, and culture behavior influence our risk tolerance and the way risks are addressed and perceived.

The reason people do not like to talk about risk is they do not understand or do not know how to anticipate risk and deal with it when it comes.

 

Question: It seems to me, something that is so easily implemented and that is so effective in removing defects as software review should be a major focus. What do you think?

Answer: Software review is one of the best techniques to identify and remove defects and should be emphasized. However, when schedule estimating is not well defined, time became critical, software engineers were often told to skip reviews and ship the product, regardless of the number of defects. Therefore, it is important to improve scheduling before focus on review. This does not mean reviews should be skipped, rather that they may not be as effective until the schedule estimates are improved. An effective peer review requires that you plan your reviews, train people to conduct them, and follow up to ensure they have been conducted accordingly and these activities can only be done when you have enough time.

 

Question: My manager wants to have data proving that process improvement really pays off. What is payoff data and how to get them?

Answer: Payoff data is always needed because managers need them to justify an investment into something new such as process improvement. Since your organization may not have those data yet, I recommend you use data from external sources until significant internal results can be demonstrated. Payoff data are the rewards/results/benefits for doing process improvement, usually expressed in quantitative terms (i.e. dollars). The payoff can be documented in a return-on-investment (ROI) model—cost to implement process improvement vs. savings resulting from process improvement. There are many published improvement data in the industry and you can go to the internet and search for them.