Câu hỏi: Thầy coi cải tiến qui trình là hoạt động gia tăng giá trị hay gánh nặng phụ thêm vào lịch biểu đã rất bận rộn rồi?

Đáp: Điều đó tuỳ vào cách nhìn của bạn và môi trường làm việc.  Nếu mọi người được trông đợi hoàn thành các dự án dựa trên lịch biểu không hiện thực, hay làm việc trong môi trường rất bận rộn cho phép việc ngắt quãng liên tục, thì nghĩ rằng họ sẽ có khả năng tạo ra cải tiến có ý nghĩa sẽ là lạc quan đấy.

Tôi tin mọi người sẽ tận hưởng làm việc với cải tiến qui trình chừng nào nó KHÔNG bị coi là gánh nặng phụ thêm. Khi mọi người hiểu rằng cải tiến qui trình có thể làm cho môi trường làm việc của họ tốt hơn, thoải mái hơn, ít bận rộn hơn, ít bị ngắt quãng hơn thì họ sẽ nhìn nó như một hoạt động gia tăng giá trị, và rồi đối xử với nó như một phần việc của họ.

 

Hỏi: Tôi muốn cải tiến qui trình của mình trong tổ chức mức 1 theo mô hình CMMI.  Bước đầu tiên tôi phải làm gì?

Đáp: Bước đầu tiên trong cải tiến qui trình phần mềm là học cách đáp ứng các mục đích và mục tiêu của dự án. Chỉ khi đã thu được khả năng làm điều này, tổ chức mới có thể tiến thêm được. Hoạt động quan trọng nhất cho tổ chức mức 1 là đạt tới khả năng đáp ứng nhất quán lịch biểu, chi phí, chất lượng và cam kết chức năng của dự án bằng việc dành ra 3% – 5% thời gian của các cán bộ để nhìn vào qui trình hiện thời, kiểm điểm yếu kém, nhận diện chỗ mạnh, thu thập dữ liệu từ các ước lượng dự án và phân tích chúng để đi tới các ước lượng tốt hơn. Chỉ với những điều này được kiểm soát đầy đủ, bạn mới có thể đặt giai đoạn cho cải tiến dài hạn.

Hỏi: Tại sao cải tiến lại là quá trình tiến hoá?

Đáp: Nó là tiến hoá bởi vì nó cần thời gian. Tất cả các qui trình đều phải được xác định, được làm tài liệu, được sử dụng, được đo, được hỗ trợ và chung cuộc được làm thành có hiệu lực.

Nó là tiến hoá bởi vì nó ngụ ý rằng cái gì đó phải được làm trước những cái khác. Kiểm soát quản lí dự án cơ sở phải được làm chủ trước khi qui trình chuẩn của tổ chức có thể được phát triển. Cách đo tuyến cơ sở phải được thiết lập trước khi cấp quản lí có thể dùng các sự kiện và dữ liệu để ra quyết định. Qui trình phải vững chãi tại chỗ và được thể lệ hoá đầy đủ trước khi tổ chức có thể bắt đầu tối ưu nó và đạt tới chất lượng thế giới.

 

Hỏi: Vai trò của Đảm bảo chất lượng phần mềm (SQA) là gì trong qui trình phát triển phần mềm? Làm sao họ có thể chịu trách nhiệm về chất lượng khi họ không phát triển phần mềm?

Đáp: Điều sai lầm là giả định rằng Đảm bảo chất lượng phần mềm (SQA) chịu trách nhiệm về chất lượng. Những người xây dựng sản phẩm phần mềm là người chịu trách nhiệm về chất lượng. Vai trò của SQA là kiểm điểm và điều phối cách những người phát triển phần mềm này thực hiện việc của họ. SQA phải tiến hành kiểm điểm và thông báo cho cấp quản lí về những sai lệch so với chuẩn, thủ tục, thực hành và qui trình đã thiết lập. Cấp quản lí phải nhấn mạnh rằng những vấn đề chất lượng này phải được sửa trước khi sản phẩm phần mềm được đưa ra. Chừng nào cấp quản lí còn chưa biểu lộ sự hỗ trợ của mình cho SQA bằng việc làm theo khuyến cáo của họ, SQA sẽ không hiệu quả.

 

Hỏi: Tại sao chúng ta nhấn mạnh quá nhiều vào cải tiến qui trình? Sao không tập trung vào con người hay công nghệ?

Đáp: Khi chúng ta nghĩ tới cải tiến qui trình phần mềm, chúng ta phải xem xét cân bằng của ba cấu phần: Qui trình, Con người và Công nghệ. Tất cả ba cấu phần này đều đóng vai trò quan trọng trong việc xác định việc cải tiến qui trình phần mềm thành công ra sao. Chúng ta cần các qui trình tốt để hoàn thành việc phát triển phần mềm. Chúng ta cần công nghệ tốt để hỗ trợ cho các qui trình này. Chúng ta cũng cần người có kĩ năng cao, có động cơ để làm việc bằng cách dùng các qui trình và công nghệ đó. Do đó, chung cuộc mọi người đều có trách nhiệm với sự thành công hay thất bại của nỗ lực cải tiến.

 

Hỏi: “Khía cạnh văn hoá” được tính tới thế nào trong khi thực hiện CMMI?

Đáp: Phần gian nan nhất của cải tiến qui trình là trong việc hiểu văn hoá của tổ chức mà bạn đang cố gắng thay đổi. Văn hoá là giá trị của tổ chức, những qui tắc và hành vi bất thành văn. Các chương trình cải tiến thành công thường là những chương trình dẫn lái thay đổi theo cùng một hướng như văn hoá. Hiển nhiên, để làm điều này, văn hoá trước hết cần được hiểu. Nó cực kì quan trọng cho tổ chức để hiểu giá trị của nó và để tăng cường chúng, nếu cấp quản lí tiếp tục thưởng cho những người làm theo cách riêng của mình và bỏ qua qui trình công việc tổ, thì giá trị văn hoá là phần thưởng cá nhân chứ không phải là công việc tổ.

Hỏi: Chỉ dẫn về qui trình thành công là gì?

Đáp: Một qui trình thành công:

• không mất đi khi nhân lực bị khan hiếm hay khi mọi người ra đi.
• được làm tài liệu, được huấn luyện, được đo, được dùng, được trắc nghiệm rồi được thể lệ hoá (mọi người đều theo nó)
• được cải tiến bởi những người thực tế dùng nó
• mọi người áp dụng nó vào cái gì đó khác
• mọi người bắt đầu hội tụ vào các vấn đề khách hàng hơn là vấn đề qui trình
• người làm phần mềm làm nó cho dù nó KHÔNG bị cấp quản lí áp đặt
• mọi người theo nó đều thấy ích lợi thực, thay đổi thực
• có cách đo rõ ràng về thay đổi (xu hướng, độ đo, dữ liệu)

 

Hỏi: Tôi mới được thuê làm người quản lí mới của SEPG vốn đã được thiết lập từ vài năm trước. Người quản lí trước bỏ đi trong thất vọng vì nhóm là một tổ không làm việc, mọi người làm điều họ muốn tương ứng theo ý kiến riêng của họ, và không chịu trách nhiệm về cái gì cả. Làm sao tôi thay đổi được họ thành tổ hiệu quả? Tôi thực muốn SEPG làm việc.

Đáp: Để lập ra một tổ hiệu quả, có năm cấu phần quan trọng:

• Mục đích tổ: ý nghĩa về mục đích và chiều hướng của tổ.
• Vai trò tổ: hiểu biết về cách thức theo đó công việc được phân công.
• Qui trình tổ: thủ tục vận hành, cách tổ tiến hành công việc của mình
• Quan hệ tổ: cách các thành viên tổ ăn cánh với nhau.
• Lãnh đạo tổ: khả năng của tổ điều phối và gióng thẳng cả qui trình và mối quan hệ tổ.

Tổ phát triển thế nào? Họ phát triển trong bốn giai đoạn và là người quản lí bạn phải cẩn thận quan sát dấu hiệu tiêu cực nào đó và có hành động:

• Hình thành: Khi các thành viên tổ bắt đầu biết nhau và thiết lập qui tắc theo đó tổ sẽ vận hành. Nhưng bạn phải cẩn thận bởi vì nhóm có thể đi tới “tâm trạng tranh cãi” và không làm cho công việc được thực hiện.
• Bão tố: Khi các thành viên tổ “đụng độ” với thách thức mà nhóm đối diện. Bạn phải cẩn thận bởi vì sự thù địch có thể bùng phát và tạo ra hận thù đeo đẳng với tổ. Một số người sẽ cố gắng chiếm lấy quyền lãnh đạo và tạo ra cảm giác xấu trong các thành viên tổ;
• Bình thường: Khi tổ đi tới cộng tác, cam kết, và cố kết nhưng đôi khi tổ sẽ cộng tác quá nhiều thì lại hội tụ vào các chi tiết và từ chối giải pháp thực;
• Hoạt động: Khi tổ thực muốn làm điều được hiến chương của nó xác định làm và tổ có thể không muốn ra đi sau khi vấn đề đã được giải quyết và tiếp tục làm mịn vấn đề vượt quá giới hạn chấp nhận được.

 

Hỏi: Yêu cầu phần mềm của chúng tôi liên tục thay đổi hàng tuần. Dường như là khách hàng của chúng tôi không thể quyết định được. Chúng tôi có thể làm gì để có hiệu quả?

Đáp: Phát triển yêu cầu vừa là cả hai quá trình thương lượng và quá trình sáng tạo. Điều này nghĩa là cấp quản lí phải được tham gia vào trong quá trình này, bên cạnh khách hàng và người phát triển phần mềm.

1)                   Khách hàng: Biết nhu cầu nghiệp vụ của họ và cách nó hỗ trợ cho để làm việc. Khi họ thảo luận các giải pháp với người phát triển, họ sẽ thu được hiểu biết mới về vấn đề của họ và thường thay đổi quan điểm.

2)                   Người phát triển: Biết các vấn đề kĩ thuật, cái gì là khả thi, và cái gì có thể được làm trong thời gian và chi phí hợp lí.

3)                   Cấp quản lí: Biết rằng các yêu cầu có thể vốn đã vô giới hạn, và doanh nghiệp tốt yêu cầu cả tính sáng tạo và tính thực tế. Họ phải kiểm điểm lại yêu cầu để đảm bảo rằng nó có thể được thực hiện bên trong thời gian và chi phí có sẵn.

Khi việc phát triển yêu cầu tiến hoá lên, thông tin mới được thu thập rất có thể sẽ ảnh hưởng tới thoả hiệp đã được thực hiện. Đó là lí do tại sao việc phát triển yêu cầu hiếm khi đầy đủ (vòng đời thác đổ không có tác dụng tốt lắm trong tình huống này). Để có hiệu quả, Người quản lí phải tham gia vào quá trình này, nhấn mạnh vào kĩ thuật làm bản mẫu, và lựa chọn vòng đời đưa ra tăng dần, là tuỳ chọn tốt hơn.

Hỏi: Trong xê mi na của thầy “Nhập môn vào Kĩ nghệ phần mềm,” thầy có nhắc rằng CMMI là cách tiếp cận theo nghĩa thông thường tới quản lí rủi ro. Quản lí rủi ro là gì?

Đáp: Trong môi trường hỗn độn, mọi người thường xuyên phản ứng với bất kì cái gì xảy ra cho họ và mất cái nhìn về tầm quan trọng của tư duy chiến lược và ra quyết định chiến lược.

Quản lí rủi ro là cách tiếp cận hệ thống tới việc ra quyết định chiến lược trong khi vẫn giải quyết với khủng hoảng. Quyết định chiến lược là một quyết định được thông báo rõ dựa trên ưu tiên đã thiết lập chỉ ra vấn đề nào phải được giải quyết trước.

Trong phát triển phần mềm, quản lí dự án là nền tảng để quản lí rủi ro. Nếu bạn không thể kiểm soát được thay đổi yêu cầu, thay đổi quản lí, lịch biểu họp và ước lượng tài nguyên thì bạn không thể quản lí được rủi ro và nếu bạn không thể quản lí được rủi ro bạn không thể cải tiến được.

 

Hỏi: Nếu một tổ chức không có qui trình được xác định (CMMI mức 3), làm sao thầy huấn luyện được kĩ sư mới theo cách “Đúng” để làm mọi sự? Với “Đúng” tôi ngụ ý bất kì cái gì tổ chức nghĩ là cách đúng?

Đáp: Tổ chức không có mức 3 để làm mọi sự cho đúng. Có nhiều cách huấn luyện kĩ sư mới: Học nghề, Kèm nghề, nhưng có lẽ quan trọng nhất là trao đổi giữa các kĩ sư về kinh nghiệm quá khứ với dự án tương tự. “Môi trường làm việc đúng” là nơi mọi người tự do trao đổi và chia sẻ các giải pháp kĩ thuật.

 

Hỏi: Tôi nghe nói về CMMI Con người hay P-CMMI. Xin thầy hãy nói cho tôi về nó? Tôi có thể lấy thông tin về điều này ở đâu?

Đáp: P-CMMI hay CMM Con người là mô hình mới được Viện Kĩ nghệ phần mềm đưa ra gần đây nhất như một bổ sung cho CMMI. Động cơ của P-CMM là cải tiến khả năng của tổ chức phần mềm để hấp dẫn, phát triển, động viên, tổ chức, và duy trì tài năng cần thiết cho việc cải tiến liên tục năng lực của tổ chức để chuyển giao sản phẩm chất lượng và thoả mãn yêu cầu của khách hàng. Mặc dầu nó được phát triển có tính tới nhu cầu của tổ chức phần mềm và cộng đồng hệ thông tin, P-CMM cũng có thể được áp dụng cho hầu hết các cấu trúc tổ chức bất kì, bất kể ứng dụng nghiệp vụ. Dựa trên thực hành tốt nhất hiện thời trong lĩnh vực tài nguyên nhân lực, P-CMMI cung cấp cho các tổ chức bản hướng dẫn về cách thu được kiểm soát về các qui trình của họ cho việc phát triển và quản lí con người.

Tương tự như CMMI, P-CMM cũng giúp thiết lập ưu tiên cho những hành động ngay lập tức, tích hợp phát triển lực lượng lao động và thiết lập văn hoá xuất sắc trong hoạt động. P-CMM bao gồm phương pháp thẩm định mà có thể được tiến hành một cách độc lập hay tích hợp với qui trình thẩm định phần mềm hiện có.

——-English version———-

 

CMMI-3

Question: Do you think process improvement is a value-added activity or extra burden on the already very busy schedule?

Answer: It depends on your view and working environment.  If people were expected to complete projects based on an unrealistic schedule, or work in a very busy work environment that allows continual interruptions, then to think that they will be able to make meaningful improvements would be optimistic.

I believe people would enjoy working on process improvement as long as it is NOT seen as an additional burden. When people understand that process improvement can make their working environment better, more pleasant, less busy, less disruption then they will see it as a value-added activity, and then treat it as part of their job.

 

Question: I want to improve my process in my level 1 organization following the CMMI model.  What should be my first step?

Answer: The first step in improving the software process is learning how to meet project goals and objectives. Only when having acquired the ability to do these, the organization can make further advances. The most important activity for a level 1 organization is achieving the ability to consistently meet project’s schedule, cost, quality and functional commitments by setting aside 3% – 5% of staff time to look at current process, review weaknesses, identify strengths, collect data from project estimates and analyze them to come up with better estimates. Only with theses completely under control, you can set the stage for long-term improvement.

 

Question: Why improvement is an evolutionary process?

Answer: It is an evolution because it takes time. All processes must be defined, documented, used, measured, improved, maintained, supported and finally enforced.

It is an evolution because it implies that something must be done before others. A basic project management control must be mastered before an organizational standard process can be developed. Baseline measurements must be established before management can use facts and data to make decision. Process must be solidly in place and fully institutionalized before organization can begin to optimize it and achieve world-class quality.

 

Question: What is the role of Software Quality Assurance (SQA) in software development process? How can they be responsible for quality when they are not developing software?

Answer: It is a mistake to assume that Software Quality Assurance (SQA) is responsible for quality. The people who develop the software products are responsible for quality. The role of SQA is to review and monitor the way these software developers perform their jobs. SQA must conduct review and inform management about deviations from established standards, procedures, practices, and processes. Management must insist that these quality problems be fixed before the software product is released. Unless management demonstrates its support for SQA by following their recommendations, SQA will be ineffective.

 

Question: Why do we emphasize too much on process improvement? Why not concentrate on people or technology?

Answer: When we think of software process improvement, we must consider the balance of three components: Process, People and Technology. All three components play an important role in determining how successful the software process improvement is. We need good processes to accomplish our software development. We need good technology to support these processes. We also need highly skilled, motivated people to do the work by using those processes and technology. Therefore, ultimately people are responsible for the success or failure of the improvement effort.

 

Question: How much of a “culture aspect” is taken when implement CMMI?

Answer: The hardest part of process improvement is in understanding the culture of the organization that you are trying to change. Culture is the organization’s values, unwritten rules, and behaviors. Successful improvement programs are usually those that drive the change in the same direction as the culture. Obviously, to do this, the culture first needs to be understood. It is extremely important for an organization to understand its values and to reinforce them, if management continues to reward the people who does thing his/her way and ignore teamwork process, then the culture value is on personal reward rather than teamwork.

 

Question: What are the indications of a successful process?

Answer: A successful process:

• Does not go away when resource gets scarce or when people leave.
• is documented, trained, measured, used, verified then institutionalized (Everybody follow it)
• Gets improved by people who are actually using it
• People apply it to something else
• People begin to focus on customer issues rather than process issues
• Software people did it even it is NOT imposed by management
• People following it see real benefits, real changes
• There are clear measures of the change (Trends, metrics, data)

 

Question: I was hired as new manager of a SEPG that was established few years ago. The former manager left in frustration since the group is a dysfunctional team, people do what ever they want according to their own opinion, and not responsible for anything. How do I change them into an effective team? I do want the SEPG to work.

Answer: To establish an effective team, there are five important components:

1)     Team goals: The team’s sense of purpose and direction.

2)     Team roles: An understanding of the ways in which work is to be allocated.

3)     Team processes: Operating procedures, the way the team conducts its business

4)     Team relationship: How the team members get along with each other.

5)     Team leadership: The capacity of the team to monitor and align both the team processes and relationship.

How do teams develop? They develop in four stages and as a manager you must be careful to observe certain negative sign and take action:

1)         Forming: When team members get to know each other and establish the rule in which the team will operate. But you must be careful because the group may go to a “debate mood” and not getting work done.

2)         Storming: When team members “collide” over the challenges facing the group. You must be careful because hostility could break out and create animosity that lingers with the team. Some people will try to assume leadership and create bad feeling among team members;

3)         Norming: When team move toward cooperation, commitment, and cohesion but sometime team will cooperate too much then focus into details and pass up the real solutions;

4)         Performing: When the team does want to do what it was chartered to do and the team may not want to quit after problems has been solved and continue to refine the problem past acceptable limit.

 

Question: Our software requirements continue to change weekly. It seems that our customer can not make up their mind. What can we do to be effective?

Answer: Requirement development is both a negotiating and a creative process. This means that management must be involved in the process, beside customer and software developer.

1)                   The customer: Know their business need and how it supposed to work. As they discuss solutions with the developers, they will gain new insights on their problems and often change their views.

2)                   The Developer: Know the technical issues, what is feasible, and what can be done in a reasonable time and cost.

3)                   The Management: Know that requirements can be inherently unlimited, and a good business requires both creativity and reality. They must review requirements to ensure that it can be done within available time and cost.

As requirement development evolves, new information is gained that will likely affect the compromises already made. That is why requirements development is seldom complete (Waterfall life cycle do not work very well in this situation). To be effective, Manager must involve in this process, insist on prototype technique, and select incremental release life cycle which is a better option.

 

Question: In your “Introduction to Software Engineering” seminar, you mentioned that the CMMI is a common sense approach to risk management. What is risk management?

Answer: In a chaotic environment, people are constantly reacting to whatever happens to them and losing sight of the importance of strategic thinking and decision-making.

Risk management is a systematic approach to making strategic decisions while dealing with crises. A strategic decision is a well informed decisions based on a set priority that indicate which problems must be dealt with first.

In software development, project management is the foundation to manage risk. If you cannot control requirements changes, managing changes, meeting schedules and resources estimates then you cannot manage risk and if you cannot manage risk you cannot improve.

 

Question: If an organization does not have a defined process (CMMI Level 3), how do you train new engineer in the “Right” way of doing thing? By “Right” I mean whatever the organization thinks is the right way?

Answer: Organization does not have to be a level 3 in order to do thing right. There is several way of training new engineer: Apprenticeship, Mentoring, but probably the most important is communication among engineers on past experience on similar projects. A “Right working environment” is where people freely communicate and share technical solutions.

 

Question: I heard of a People CMMI or P-CMMI. Can you tell me about it? Where can I get information on this?

Answer: P-CMMI or People CMM is the latest model released by the Software Engineering Institute as a complement to the CMMI. The motivation of the P-CMM is to improve the ability of the software organization to attract, develop, motivate, organize, and retain the talent needed to continuously improve the organization capability to deliver quality products and satisfy customer requirements. Although it is developed with the needs of software organization and information systems community in mind, the P-CMM can be applied to almost any organization structures, regardless of the business applications.

Based on the current best practices in the field of human resource, the P-CMMI provides organizations with guidance on how to gain control of their processes for developing and managing people.

Similar to the CMMI, the P-CMM also helps set priorities for immediate actions, integrates workforce development and establishes a culture of operational excellence. The P-CMM include an assessment method that can be conducted independently or integrate with the existing software assessment process.