Đáp: Sau đây là các bước trong việc đánh giá điển hình:
1. Xác định phạm vi, mục đích cải tiến và thiết lập sự bảo trợ.
2. Thiết lập kết cấn nền thực hiện (SEPG)
3. Lập kế hoạch chi tiết đánh giá.
4. Chuẩn bị và huấn luyện tổ đánh giá.
5. Lập hồ sơ các thành viên đánh giá (thành viên dự án phần mềm).
6. Người quản trị bảng hỏi CMMI.
7. Phân tích đáp ứng bảng hỏi.
8. Kiểm điểm vật phẩm và tài liệu.
9. Tiến hành phỏng vấn với các đại diện miền chức năng (SQA, CM).
10. Tiến hành phỏng vấn người quản lí, người hành nghề, người lãnh đạo dự án.
11. Hợp nhất dữ liệu thu được từ các bảng hỏi, kiểm điểm và phỏng vấn.
12. Thiết lập phát kiến và khuyến cáo.
13. Xác định mức trưởng thành.
14. Lập hồ sơ bảo trợ về kết quả đánh giá.
15. Lập hồ sơ các thành viên đánh giá về kết quả.
16. Lập hồ sơ tổ chức về kết quả đánh giá.
17. Chuẩn bị báo cáo đánh giá cuối cùng.
Việc đánh giá nên được tiến hành bởi những người đánh giá được SEI công nhận và dựa trên nguyên tắc mật. Độ chính xác và tính hữu dụng của kết quả phụ thuộc cực kì lớn vào khả năng của mọi người nói một cách tự do và không sợ trừng phạt, trù úm. Nhà tư vấn không đủ tư cách có thể làm mọi người lẫn lộn, đặt mong đợi sai, và đưa tổ chức xuống con đường sai với những hứa hẹn nhưng không giữ lời và cuối cùng làm hỏng việc cải tiến.
Hỏi: Tại sao SEPG cũng chịu trách nhiệm cho việc chuyển giao công nghệ trong tổ chức? Tại sao không phân công cho người kĩ thuật khác làm nhiệm vụ này?
Đáp: Khi công nghệ phần mềm mới được đưa vào trong tổ chức, những thay đổi có ý nghĩa cần được xảy ra trong tổ chức đó để đảm bảo việc chấp nhận thành công. Điều này là đúng dù công nghệ là qui trình (như Kiểm điểm), kỉ luật (như Quản lí dự án) hay công cụ (như RUP).
Trong quá khứ, tổ chịu trách nhiệm đưa vào công nghệ mới cho tổ chức thường là những người kĩ thuật nhưng nhiều việc chuyển giao công nghệ đã thất bại. Dựa trên dữ liệu được thu thập tôi thấy rằng phần lớn các thất bại đều không phải công nghệ hay qui trình mà do thiếu chỉ dẫn và huấn luyện kĩ năng trong những người chịu trách nhiệm làm cho thay đổi xảy ra. Phần lớn mọi người đều có kĩ năng kĩ thuật nhưng không có kĩ năng cần thiết để lập kế hoạch và thực hiện việc chuyển giao công nghệ thành công.
Các thành viên SEPG là các nhà chuyên môn kĩ thuật, được huấn luyện để đưa thay đổi vào trong tổ chức và rất quen thuộc với “qui trình thay đổi.” Do đó, họ là những người có thể nhất được phân công làm “tác nhân thay đổi” chịu trách nhiệm cho việc chuyển giao công nghệ trong tổ chức.
Hỏi: Định nghĩa về tổ kĩ nghệ phần mềm “tốt” là gì? Người làm phần mềm có phải làm việc trong “tổ” không?
Đáp: Câu hỏi của bạn làm tôi nghĩ tới một cuộc họp tôi có với một nhóm người làm phần mềm từ một công ti. Họ nói rằng “tổ phần mềm tốt” là tổ được tạo nên từ người tốt – định nghĩa về “người tốt” là họ và chỉ họ.
Tổ kĩ nghệ phần mềm “tốt” có thể khó định nghĩa bởi vì một số vấn đề như sự khác biệt về nền tảng và phong cách cũng như cảm giác cá nhân về “có tính sáng tạo cao” hay “tốt hơn” ai đó khác. Tuy nhiên, với việc đưa vào bộ môn kĩ nghệ phần mềm, thời của “tôi là trung tâm” đã qua rồi. Tôi đã biết nhiều tổ phần mềm tốt nơi mọi người đều trưởng thành, chuyên nghiệp, và sẵn lòng chia sẻ tri thức của mình với nhau. Tổ tốt yêu cầu trộn lẫn các kĩ năng, người nọ bổ sung cho người kia để đạt tới mục đích chung. Điều đó áp dụng cho bất kì tổ nào và phần mềm là không khác.
Hỏi: Thầy coi dự án thành công là gì? Nhân tố mấu chốt là gì?
Đáp: Dự án được coi là thành công chỉ nếu các mục tiêu chi phí, lịch biểu, và chất lượng được đáp ứng. Nhân tố mấu chốt trong dự án là qui trình ước lượng, điều giúp cho người quản lí dự án trong việc quản lí và kiểm soát chi phí dự án và theo lịch biểu để đạt tới chức năng được yêu cầu. Người quản lí dự án chỉ nên cam kết với dự án khi họ có ước lượng chi phí và lịch biểu mà theo đó họ có mức độ tin cậy nào đó.
Không một phương pháp ước lượng chuẩn nào là phù hợp cho mọi kiểu dự án. Từng tổ chức đều cần định nghĩa một qui trình ước lượng phù hợp với nhu cầu riêng của mình.
Một số mục cần xem xét khi xác định qui trình ước lượng của bạn bao gồm:
Khi nào việc ước lượng và tái ước lượng được thực hiện?
Ai thực hiện ước lượng?
Cái gì đặc biệt được ước lượng, như nỗ lực, tải, phần mềm, kích cỡ v.v.?
Làm sao điều phối và kiểm soát ước lượng?
Nếu có sai biệt giữa thực tại và ước lượng, khi nào bạn làm tái ước lượng?
Điều gì xảy ra khi ước lượng không được cấp quản lí chấp nhận? không được khách hàng chấp nhận?
Nếu yêu cầu thay đổi khi nào bạn làm tái ước lượng?
Khi nào bạn sẽ không làm tái ước lượng?
Cách đo nào của các dự án trước (cách đo dự án, cách đo qui trình) được ghi lại trong cơ sở dữ liệu tổ chức?
Cách đo của các dự án trước được duy trì thế nào để cải tiến ước lượng chi phí phần mềm?
Hỏi: Tại sao mọi người lại phí thời gian học các kĩ năng cải tiến qui trình khi họ có thể học các kĩ năng khác như JAVA, C++, và OOD để làm nhiều tiền hơn và có cơ hội làm việc tốt hơn?
Đáp: Các kĩ năng cải tiến qui trình phần mềm ít được chú ý hơn cái gọi là kĩ năng “kĩ thuật” như C++, JAVA, tích hợp mạng, và OOD. Vậy mà nhiều tổ chức lại tìm kiếm cải tiến vị thế cạnh tranh của họ qua các qui trình phần mềm tốt hơn, nhu cầu về các nhà chuyên môn cải tiến qui trình có kĩ năng cũng đang tăng trưởng. Có mối quan tâm tăng lên về cải tiến qui trình phần mềm trên khắp thế giới. Nhu cầu về các nhà chuyên môn này đang tăng trưởng nhanh hơn nhu cầu về cái gọi là “kĩ năng kĩ thuật” với đề nghị việc có lương cao hơn nhiều các lĩnh vực khác. Bất kì ai cũng có thể học JAVA và C++ ở trường học nhưng chưa có trường nào dạy kĩ năng về cải tiến qui trình. Bạn phải thực hành nó và học nó.
Hỏi: Một nhà tư vấn khuyên chúng tôi làm tài liệu mọi thứ để cho chúng tôi có thể đạt được CMMI mức 3. Dường như là mọi người đều xô vào việc viết tài liệu qui trình bây giờ. Cải tiến qui trình có phải tất cả là vậy không?
Đáp: Cải tiến qui trình phần mềm được xác định là “các hoạt động cải tiến qui trình phần mềm tổ chức để đạt tới kết quả đặc biệt.” Kết quả cuối cùng có thể là việc giảm chi phí, khiếm khuyết, và thời gian chu kì nhưng không bao giờ là khối lượng tài liệu khổng lồ. Xin đừng rơi vào cái bẫy của việc sinh ra tài liệu qui trình để đạt tới mức trưởng thành CMMI vô nghĩa. Không tổ chức nào đã bao giờ đạt tới bất kì mức nào bằng việc sinh ra giấy tờ vì điều đó chẳng có nghĩa gì. Cải tiến yêu cầu tổ chức sửa chữa các vấn đề quản lí dự án – lập kế hoạch, ước lượng, theo dõi – và dứt khoát không sinh ra nhiều giấy tờ.
Hỏi: Tôi bị thuyết phục rằng thay đổi là vấn đề kĩ thuật và những người kĩ thuật – người hiểu nó – phải làm nó. Là người quản lí, vai trò của tôi là không chen vào cách của họ, nhưng trao quyền cho họ làm bất kì cái gì họ thấy cần làm. Thầy nghĩ gì?
Đáp: Ngược lại, tôi mạnh mẽ tin tưởng rằng thay đổi là vấn đề quản lí, không phải là vấn đề kĩ thuật. Tôi tin tưởng quản lí cần hội tụ vào các mục tiêu doanh nghiệp cần thay đổi như giảm thời gian chu kì, giảm chi phí, tăng chất lượng và ra quyết định về cách hoàn thành các mục tiêu đó. Cấp quản lí phải giữ vai trò tích cực trong cam kết thay đổi và hỗ trợ thay đổi khi nó xảy ra, điều phối và quản lí qui trình thay đổi, và bám theo quyết định rằng thay đổi là quan trọng cho doanh nghiệp. Nhớ “Thay đổi là không tránh khỏi, tồn tại là tuỳ chọn.” Dừng tranh cãi liệu thay đổi là vấn đề quản lí hay vấn đề kĩ thuật đi mà hiểu rằng thay đổi là vấn đề kinh doanh mà mọi nhà quản lí đều cần quản lí.
Hỏi: Tại sao chúng ta tuân theo khuôn khổ CMMI? Cái gì là khác biệt giữa khuôn khổ này và các khuôn khổ khác như khuôn khổ kiến trúc của Zachman?
Đáp: CMMI là khuôn khổ cho cải tiến qui trình phần mềm. Nó đã được dùng trong toàn ngành công nghiệp với nhiều thành công. Việc chấp nhận khuôn khổ này cũng là kì lạ, cả từ quan điểm của cấp quản lí và người hành nghề. CMMI đại diện cho khuôn khổ đầy đủ với các định nghĩa và ví dụ bao quát lập kế hoạch, thiết kế, và khía cạnh quản lí phần mềm. Nó cũng gợi ý một trình tự mà một tổ chức có thể theo để cải tiến qui trình phần mềm của mình. Nó cung cấp cách đo để điều phối qui trình triển khai và phần lớn trong tất cả, nó mang nghĩa thông thường thuần tuý.
Khuôn khổ kiến trúc Zachman là công cụ để mô tả các khía cạnh khác hay cách nhìn về hệ thống phần mềm nhưng không phải là khuôn khổ để cải tiến qui trình phần mềm.
Hỏi: Một tổ chức cần bao nhiêu độ đo để đạt tới CMM mức 2? Chúng tôi có thể tìm nó ở đâu?
Đáp: Theo ý kiến của tôi nhiều tổ chức đã có cách đo và độ đo cần cho CMMI mức 2 như Khiếm khuyết, Kích cỡ, Thời gian và Chi phí nhưng những dữ liệu này phải được phân tích và sử dụng. Đã tiến hành hàng trăm việc đánh giá, tôi thấy phần lớn các tổ chức đã tràn ngập khối lượng dữ liệu những chưa bao giờ được người quản lí dự án dùng.
Hỏi: Thầy đổi người thế nào? Sao người làm phần mềm bao giờ cũng cư xử theo cách họ làm?
Đáp: Hành vi con người được xác định bởi niềm tin (điều họ cảm thấy chắc chắn) và giá trị (điều họ coi là quan trọng nhất). Dưa trên định nghĩa này, người làm phần mềm không khác bất kì ai khác.
Niềm tin được tạo nên từ kinh nghiệm trước đây và thông tin nhận được. Giá trị là điều cá nhân coi là quan trọng trong cuộc sống của họ. Để thay đổi hành vi của một người, người ta cần hiểu giá trị và niềm tin cái gây ra hành vi. Bạn có thể giúp sửa bất kì niềm tin nào dựa trên thông tin sai – huấn luyện và giáo dục thực sự giúp ích và trao đổi cũng vậy. Bạn cũng có thể trắc nghiệm ưu tiên giá trị của một người và hậu quả của hành vi kết quả – thưởng và phạt giúp điều này và hướng dẫn và huấn luyện cũng giúp cho điều này).
Hỏi: Cấp quản lí của tôi không tin phần mềm là quan trọng và do đó không cam kết cải tiến. Tôi có thể làm gì để thuyết phục họ rằng phần mềm là quan trọng?
Đáp: Bạn có thể nhắc nhở người quản lí của bạn rằng phần mềm điều khiển sản phẩm của bạn. Nó tới với khiếm khuyết và để cải tiến sản phẩm, tổ chức cần hội tụ vào qui trình tạo ra sản phẩm. Chất lượng sản phẩm của bạn trực tiếp ảnh hưởng tới tuyến đáy của tổ chức của bạn và chừng nào tuyến đáy mà không quan trọng, tổ chức của bạn phải nhìn vào phần mềm như một trong các nhân tố quan trọng cần cải tiến. Theo cách này, tổ chức của bạn sẽ không bao giờ thay đổi trừ phi văn hoá của tổ chức thay đổi và mọi thay đổi phải bắt đầu từ trên đỉnh – người quản lí.
Hỏi: Thầy cải tiến phần mềm thế nào khi những người thực hiện nó thuộc vào vài nhóm và từng nhóm đều có phần hành động?
Đáp: Các nhà chuyên môn phần mềm từ lâu đã tham gia vào trong tranh luận về qui trình phần mềm và người thực hiện chúng. Người thu thập yêu cầu, người thiết kế, người phát triển và người kiểm thử thường xuyên dường như có mối quan hệ đối địch, mặc dầu họ tất cả đều có chung cùng mục đích – sản phẩm phần mềm chất lượng cao. Nhóm của họ hình thành tốt thế nào cũng không thành vấn đề, các qui trình không thể nào thành công nếu các thành viên không hoà thuận với nhau.
Hỏi: Đặc trưng của việc là người quản lí giỏi cho cải tiến qui trình là gì?
Đáp: Người quản lí giỏi cho cải tiến qui trình bao giờ cũng:
Có ý thức về chủ định, biết mục đích và mục tiêu và chủ định của cải tiến.
Làm cho mọi sự vận động và làm mọi sự xảy ra.
Cho chỉ đạo rõ ràng về cách tổ chức sẽ cải tiến và không làm những điều nào đó là tuỳ chọn.
Lập kế hoạch và theo dõi để đảm bảo mọi thứ xảy ra.
Điều phối các hoạt động để xem liệu có gì sai lệch, làm hành động sửa chữa.
Nhấn mạnh vào dữ liệu cải tiến, thừa nhận người lãnh đạo và người đóng góp trong tổ chức.
Hỏi: Rủi ro phần mềm và quản lí rủi ro là gì?
Đáp: Rủi ro là các biến cố tương lai với xác suất xuất hiện và tiềm năng tổn thất. Nhiều vấn đề nảy sinh trong nỗ lực phát triển phần mềm đầu tiên được biết tới như rủi ro bởi ai đó trong dự án. Được phát hiện đúng lúc, rủi ro có thể được tránh, được khử bỏ, hay có tác động bị giảm nhẹ. Vấn đề là rủi ro có thời điểm xảy ra. Hay cách khác để nhìn vào nó – mọi vấn để xuất hiện trong dự án phát triển phần mềm đều có rủi ro vào một lúc nào đó.
Quản lí rủi ro phần mềm là kĩ thuật dựa trên khái niệm về giảm thiểu rủi ro bằng việc hỏi các câu hỏi nền tảng:
1. Xác suất – khả năng vấn đề sẽ xuất hiện là gì?
2. Tác động – vấn đề sẽ gây tốn kém bao nhiêu nếu nó xuất hiện?
3. Khung thời gian – vấn đề có thể xuất hiện khi nào?
Quản lí rủi ro phần mềm nhận diện rủi ro, phân tích nó, trao đổi nó với mọi người trong tổ chức và đi tới giải pháp khử bỏ hay giảm nhẹ rủi ro. Một lần nữa, tại sao chúng ta cần quản lí rủi ro? Được phát hiện đúng lúc, rủi ro có thể được tránh, được khử bỏ, hay có tác động của nó được làm nhẹ đi.
Question: Our organization would like to conduct an appraisal to determine where we are in the CMMI maturity levels. What are the steps and issues?
Answer: Following are the steps in a typical appraisal:
1. Determine the scope, improvement goals and establish sponsorship.
2. Establish implementation infrastructure (SEPG)
3. Plan appraisal details.
4. Prepare and train an appraisal team.
5. Brief appraisal participants. (Software projects members)
6. Administer CMMI questionnaires.
7. Analyze questionnaire responses.
8. Review artifacts and documents.
9. Conduct interviews with functional area representatives (SQA, CM).
10. Conduct interviews with managers, practitioners, project leads.
11. Consolidate data obtained from the questionnaire, reviews and interviews.
12. Establish findings and recommendations.
13. Determine maturity level.
14. Brief sponsor on appraisal results.
15. Brief appraisal participants on results.
16. Brief organization on appraisal results.
17. Prepare appraisal final report.
The appraisal should be conducted by a SEI qualified appraiser and based on the principle of confidentiality. The accuracy and usefulness of the results is critically dependent upon everyone’s ability to speak freely and without fear of retribution. An unqualified consultant can confuse people, set wrong expectations, and lead the organization down the wrong path with promises but not kept and eventually improvement failure.
Question: Why is the SEPG also responsible for technology transfer in an organization? Why not assign other technical people to do this task?
Answer: When a new software technology is introduced into an organization, significant changes need to take place in that organization to ensure successful adoption. This is true whether the technology is a process (such as Reviews), a discipline (such as Project Management) or a tool (such as RUP).
In the past, teams responsible for introducing new technologies to the organization often were technical people but many technology transfers have failed. Based on data collected I found that most failures are not the technology or the process but the lack of instruction and training skills in the people responsible for making change happen. Most have technical skills but not the necessary skills to plan and implement a successful technology transfer.
SEPG members are technical professionals, trained to introduce changes in an organization and very familiar with the “change process”. Therefore, they are the most likely to be assigned as the “change agents” responsible for technology transfer in an organization.
Question: What is the definition of a “good” software engineering team? Do software people must work in “team”?
Answer: Your question makes me think of a meeting I had with a group of software people from a company. They said that a “good software team” is one that is made up of good people—the definition of “good people” being them and only them.
A “good” software engineering team can be difficult to define because of some issues such as differences in background and style as well as an individual sense of “being highly creative” or “better” than someone else. However, with the introduction of software engineering disciplines, the days of the “self centered” are gone. I have known many good software teams where people are mature, professional, and willing to share their knowledge with each other. Good teams require a mixture of skills that complement one another in order to achieve common goals. That applies to any team and software is no different.
Question: What do you consider a successful project? What are the critical factors?
Answer: A project is considered a success only if the cost, schedule, and quality objectives are met. The critical factor in a project is the estimation process which helps project managers in managing and controlling the project costs and in scheduling to achieve the required functionality. Project managers should only commit to a project when they have a cost and schedule estimate for which they have a certain level of confidence.
No single standard estimating method is suited for every type of project. Each organization needs to define an estimating process suited to its own needs.
Some items to consider when defining your estimating process include:
Question: Why are people wasting time learning process improvement skills when they could learn other skills such as JAVA, C++, and OOD to make more money and have better employment opportunities?
Answer: Software Process Improvement skills get less attention than the so-called “technical” skills such as C++, JAVA, network integration, and OOD. Yet as more organizations seek to improve their competitive position through better software processes, the need for skilled process improvement professionals is also growing. There is a growing interest in software process improvement all over the world. The demand for this professional is growing faster than the demand for so called “technical skills” with job offers at much higher salaries than other fields. Anyone can learn JAVA and C++ in school but there is no school teaching the skill of process improvement yet. You have to practice it and learn it.
Question: A consultant advised us to document everything so we can achieve CMMI level 3. It seems like everybody is rushing to write process documentation now. Is this what process improvement is all about?
Answer: Software process improvement is defined as “activities that improve organization software processes to achieve a specific result.” The end result may be a reduction in cost, defects, and cycle time but never a huge volume of documentation. Please do not fall into the trap of generating process documentation to achieve a meaningless CMMI maturity level. No organization ever achieved any level by generating paper since it does not make any sense. Improvement requires an organization to fix project management issues—planning, estimating, tracking—and it is definitely not generating more paper.
Question: I am convinced that change is a technical issue and technical people—people who understand it—must do it. As a manager, my role is not getting in their way, but empowering them to do whatever they need to do. What do you think?
Answer: On the contrary, I strongly believe that change is a management issue, not a technical issue. I believe management needs to focus on the business objectives of change such as reducing cycle time, reducing costs, increasing quality and making decisions about how to accomplish those objectives. Management should take an active role in commitment to change and supporting change as it goes, monitoring and managing the change process, and sticking with the decision that change is important to the business. Remember “Change is inevitable, survival is optional.” Stop debating whether change is a management issue or a technical issue rather understand that change is a business issue that every manager needs to manage.
Question: Why do we follow the CMMI framework? What is the difference between this framework and others such as the Zachman’s architecture framework?
Answer: The CMMI is a framework for software process improvement. It has been used throughout the industry with a lot of success. The acceptance of this framework is also phenomenal, both from the management and practitioner viewpoints. The CMMI represents a complete framework with definitions and examples that cover the planning, design, and management aspect of software. It also suggests a sequence which an organization can follow to improve its software processes. It offers measurements to monitor the deployment process and most of all, it is purely common sense.
Zachman’s architecture framework is a tool to describe different aspects or views of a software system but not a framework to improve the software process.
Question: How many measurements does an organization need to achieve CMM level 2? Where do we find them?
Answer: In my opinion many organizations already have metrics and measurements needed for CMMI level 2 such as Defects, Size, Time and Cost but these data must be analyzed and used. Having conducted hundreds of appraisals , I found that most organizations already had an overwhelming amount of data collected but never used by project managers.
Question: How do you change people? Why do software people always behave the way they do?
Answer: A person’s behavior is determined by beliefs (what they feel certain about) and values (what they consider most important). Based on this definition, software people are not different from anyone else.
Beliefs are formed from previous experiences and information received. Values are what individuals consider important in their life. To change the behavior of a person, one needs to understand the values and beliefs that are causing the behavior. You could help to correct any beliefs that are based on false information—training and education really helps and so does communication. You could also verify the person’s value priorities and the consequences of the resulting behaviors—reward and punishment helps and so does mentoring and coaching).
Question: My management does not believe software is important and therefore is not committed to improvement. What can I do to convince them that software is important?
Answer: You may want to remind your manager that software drives your products. It comes with defects and in order to improve your products, the organization needs to focus on the process that creates your products. Your products’ quality directly affects your organization’s bottom line and unless the bottom line is not important, your organization must look at software as one of the important factors to improve. By the way, your organization will never change unless the organization’s culture changes and every change begins with the one on top—the manager.
Question: How do you improve software when the people who implement it belong to several groups and each has a piece of the action?
Answer: Software professionals have long been engaged in debate over software processes and the people who implement them. Requirements gathering people, designers, developers and testers frequently seem to have adversarial relationships, although they all share the same goal—a high-quality software product. No matter how well their group performs, the processes are unlikely to succeed if the participants fail to get along.
Question: What are characteristics of being a good manager for process improvement?
Answer: A good manager for process improvement always:
Question: What are software risks and risk management?
Answer: Risks are future events with a probability of occurrence and a potential for loss. Many of the problems that arise in software development efforts were first known as risks by someone in the project. Upon timely discovery, risks can be avoided, eliminated, or have their impacts lessened. A problem is a risk whose time has come. Or another way of looking at it—every problem that occurs in a software development project was a risk at one time.
Software risk management is a technique that is based on the concept of mitigating risks by asking the fundamental questions:
1. Probability—what is the likelihood that a problem will occur?
2. Impact—how much will the problem cost if it does occur?
3. Time frame—when is the problem likely to occur?
Software risk management identifies the risk, analyzes it, communicates it to everybody within the organization and comes up with a solution to eliminate or reduce the risk. Once again, why do we need risk management? Upon timely discovery, risks can be avoided, eliminated, or have their impacts lessened.
