Hỏi: Tại sao tổ chức cần cải tiến qui trình phần mềm của mình?

Đáp: Chất lượng của sản phẩm bao giờ cũng phụ thuộc vào chất lượng của qui trình tạo ra sản phẩm đó. Để tạo ra phần mềm chất lượng cao, tổ chức cần cải tiến qui trình phần mềm của mình.

Mô hình trưởng thành năng lực phần mềm tích hợp – Software Capability Maturity Model Integration (CMMI), được phát triển tại Viện Kĩ nghệ phần mềm (SEI) tại Đại học Carnegie-Mellon (CMU), là cách tiếp cận đã được chứng minh về quản lí “qui trình” để tạo ra phần mềm chất lượng cao. Nó là tập hợp các phương pháp quản lí có hệ thống và có kỉ luật để giúp cho tổ chức trưởng thành hướng tới mức “năng lực” qui trình cao hơn.  Tuy nhiên, để làm điều đó cho đúng, bên cạnh việc cải tiến qui trình, tổ chức phải cam kết đầu tư đáng kể vào con người của họ nữa.

 

Hỏi: Tại sao nhiều cải tiến phần mềm thất bại? Ngay cả với tài nguyên nhân lực và công cụ tốt nhất, nhiều việc cải tiến vẫn không tạo ra tiến bộ.

Đáp: Phần lớn nỗ lực cải tiến thất bại bởi vì không đề cập tới “Điều bất ngờ” hay “sự chống lại thay đổi.”  Ngay cả với công nghệ tốt nhất, nhiều tổ chức vẫn thất bại, không phải bởi vì công nghệ mà bởi việc chấp thuận nó. Điều không may là nhiều tổ chức thường lặp lại hình mẫu này qua mỗi lần đưa vào công nghệ mới. Nhiều người tin rằng công nghệ mới sẽ làm thay đổi mọi thứ nhưng điều đó không xảy ra bởi vì tổ chức không đề cập tới niềm tin và hành vi đã ăn sâu, điều giữ lại hành vi phòng thủ của tổ chức. Mọi người không muốn thay đổi chừng nào họ còn chưa phải thay đổi và sự chống lại thay đổi này cuối cùng sẽ dừng qui trình thay đổi và dần dần phá huỷ nhiệt tình và sức sống của nỗ lực thay đổi. Để thay đổi, tổ chức không thể dựa vào công nghệ mà họ muốn đem vào mà phải đề cập tới khía cạnh hành vi và chính lãnh đạo cao nhất phải chỉ đạo điều đó bằng tầm nhìn, mục đích, nhân lực, khuyến khích và điều phối tích cực mọi thay đổi.

Hỏi: Tổ chức của chúng tôi cần cải tiến nhưng chúng tôi bắt đầu thế nào? Chúng tôi đều là kĩ sư chứ không phải người quản lí và ai sẽ chỉ đạo chúng tôi cải tiến?

Đáp: Người ta nói rằng chỉ đạo bao giờ cũng bắt đầu từ trên đỉnh. Tất nhiên điều này là đúng, nhưng tôi tin ham muốn cải tiến cũng có thể được tìm thấy ở đáy của tổ chức và ở mọi chỗ giữa. Để cải tiến người ta phải có ham muốn thay đổi và thái độ này có thể được tìm thấy và phải được thực hành bởi các nhân viên ở mọi mức của tổ chức. Đó là cách duy nhất theo đó tổ chức có thể làm cho hầu hết người quản lí và nhân viên như một, đạt tới mục đích chiến lược của nó, hoàn thành hứng khởi nghề nghiệp cá nhân của mọi người trong tổ chức, và đặt nền tảng cho qui trình và sản phẩm chất lượng.

Bất kì kĩ sư nào khuyến nghị một giải pháp cải tiến qui trình phần mềm cũng đều biểu lộ quyền lãnh đạo — theo các tham biến về vị trí của người đó trong tổ chức — theo cùng cách như một CEO khởi động một sáng kiến để biến đổi toàn bộ công ti.

Mọi người đều có thể cải tiến cái gì đó ở bất kì mức nào và chẳng thành vấn đề liệu bạn ở tuyến đầu hay tuyến đỉnh. Nếu bạn được trao quản lí một văn phòng với quyền lực của văn phòng đó, bạn sẽ thêm gì vào văn phòng ở trên và bên ngoài những quyền lực đó? Bạn có động viên mọi người cải tiến không? Bạn có đem điều tuyệt hảo và tầm nhìn vào điều tối thượng là mục tiêu của văn phòng đó hay thậm chí của toàn thể công ti? Mọi người đều có thể thực hiện cải tiến bằng việc là người đóng góp cá nhân tại bất kì mức nào của tổ chức.

 

Hỏi: Tổ chức phần mềm trưởng thành đầy đủ trông giống cái gì? Thuộc tính của các tổ chức CMMI mức 4 hay 5 là gì?

Đáp: Trong tổ chứ trưởng thành đầy đủ (Mức 4 và 5), chất lượng được xác định và dự đoán được. Chi phí và lịch biểu bao giờ cũng được đáp ứng. Qui trình phát triển phần mềm được xác định tốt và một số được đặt dưới kiểm soát thống kê. Vai trò và trách nhiệm là rõ ràng, mọi người được huấn luyện để thực hiện vai trò của họ và làm chúng tốt. Kỉ luật đo phần mềm bao giờ cũng được thực hành. Công nghệ hỗ trợ qui trình được đánh giá và dùng có hiệu quả. Chương trình huấn luyện được xác định để thúc đẩy sự tăng trưởng tài năng và thiết lập năng lực cốt lõi. Và thành công bao giờ cũng dựa trên năng lực của tổ chức giải quyết những thách thức và tài năng cá nhân nở hoa bên trong đó.

 

Hỏi: Xem như phần thưởng cho người quản lí dự án thành công, tôi được phân công việc của người quản lí SEPG. Tôi không chắc liệu nó là phần thưởng hay trừng phạt?

Đáp: Nếu cải tiến qui trình là quan trọng cho ông chủ của bạn thế thì hãy coi nó là phần thưởng. Sau rốt chính điều mất chốt cho thành công của tổ chức của bạn chẳng phải là giảm chi phí, tăng năng suất và chất lượng sao? Nếu ông chủ của bạn không coi cải tiến qui trình là “mấu chốt”, ông ấy có lẽ đã phân công nó cho bất kì người nào sẵn có, không cho người quản lí dự án thành công như bản thân bạn. Chúc mừng cuộc hành trình cải tiến qui trình.

 

Hỏi: Tổ chức của chúng tôi mới bắt đầu cải tiến qui trình phần mềm những chúng tôi không muốn phạm sai lầm giống các tổ chức khác. Thầy có gợi ý gì không?

Đáp: Nhiều tổ chức quả có phạm phải sai lầm khi cải tiến qui trình phần mềm của họ. Một số là do thiếu kinh nghiệm; số khác là kết quả của việc chống lại thay đổi. Một cách tự nhiên sai lầm có thể được tránh bằng việc tuân theo các bài học rút ra sau đây từ những tổ chức khác. Đây là vài lời khuyên để tránh những sai lầm này:

1. Bao giờ cũng xác định các mục đích cải tiến hợp lí, đo được và đạt được.

2. Mục đích cải tiến phải được gắn với mục tiêu doanh nghiệp.

3. Lập kế hoạch về nhân lực thích hợp, đặc biệt nhân lực có kĩ năng.

4. Coi cải tiến qui trình như dự án, mọi nỗ lực cải tiến đều phải được lập kế hoạch và theo dõi cho tới khi đóng lại.

5. Không phí thời gian tìm giải pháp mạnh mẽ mà tập trung vào nhiều giải pháp nhỏ.

6. Đảm bảo mọi mức quản lí đều có tham gia.

7. Đảm bảo mọi giải pháp đều được thử nghiệm để chắc chắn nó có tác dụng đúng trước khi dùng chúng trong toàn tổ chức (thể lệ hoá).

8. Không cố gắng xác định qui trình chuẩn phần mềm của tổ chức (OSSP) quá sớm.

9. Thiết lập tuyến cơ sở đo sớm nhất có thể được.

10. Biết khi nào bạn cần có giúp đỡ và yêu cầu điều đó. Đừng cố gắng tự mình thực hiện nó.

Hỏi: Cấp quản lí của chúng tôi đang lập kế hoạch so sánh dữ liệu giữa các nhóm phần mềm và tìm cách xếp hạng thấp nhất để có “hành động chỉnh sửa.” Đó tất cả là về cách đo nào vậy?

Đáp: Để có cách đo có nghĩa, việc thu thập dữ liệu phải được tiếp cận tới với sự cẩn thận lớn và dữ liệu phải được xác định trước khi việc thu thập bắt đầu. Khi các nhóm khác nhau thu thập dữ liệu và không dùng cùng định nghĩa, kết quả là không so sánh được, mặc dù việc so sánh chúng có thể có nghĩa ở mức quản lí cao nào đó. Xu hướng so sánh các nhóm và gây sức ép lên những nhóm xếp hạng thấp là không thích hợp và dùng sai dữ liệu. Tôi không nghĩ rằng hai nhóm là tương tự bởi bất kì cách đo đơn giản nào. Biến thiên về độ phức tạp của nhiệm vụ gây ra bởi các kiểu sản phẩm khác nhau, các nền, khách hàng, môi trường có thể là có ý nghĩa. Dữ liệu năng suất là vô nghĩa trừ phi được xác định tường minh; chẳng hạn, số các dòng mã theo tháng có thể thay đổi đáng kể  tuỳ theo việc diễn giải các tham biến. Tôi tin đếm dòng mã chỉ nên bao hàm mã mới và được thay đổi trong tất cả các lệnh đã giao hàng.

Tôi tin tưởng mạnh mẽ rằng dữ liệu KHÔNG nên được dùng để so sánh các nhóm, dự án hay cá nhân. Mục đích duy nhất của việc đo là để giải thích sản phẩm đang được xây dựng và cung cấp cơ sở không chính thức cho việc cải tiến qui trình. Khi dùng cho các mục đích khác, bản thân dữ liệu sẽ bị giảm giá trị.

 

Hỏi: Tại sao người dùng không tin vào người phát triển? Tại sao họ không thể làm việc như các đối tác?

Đáp: Tôi tin đó là vấn đề tín nhiệm. Nhiều người phát triển phần mềm có xu hướng tách bản thân họ ra khỏi khách hàng vì chuyên gia công nghệ không có hiểu biết rằng họ thuộc vào chức năng hỗ trợ và không bình đẳng với khách hàng.

Đối tác bình đẳng yêu cầu tin cậy và kính trọng, và để làm điều đó, người phát triển phần mềm phải hội tụ vào việc tạo ra danh tiếng về sự tin cậy, trước khi nhấn mạnh vào tri thức chuyên gia của mình. Để thu được sự tin cậy của khách hàng, người phát triển phần mềm phải học về công việc của khách hàng, qui trình của họ, nhu cầu của họ, yêu cầu của họ, chi phí của họ v.v. Đừng dùng cách nói kĩ thuật của bạn mà khách hàng không hiểu, điều đó bao giờ cũng tạo ra không tin cậy. Đừng nhảy xổ vào gợi ý giải pháp kĩ thuật mà cố gắng giúp họ thám hiểm các tuỳ chọn phi kĩ thuật trước hết. Chỉ bằng cách làm việc cùng nhau, chúng ta mới có thể tìm ra nền tảng chung và với thời gian, thiết lập nên quan hệ đối tác bình đẳng thực sự.

 

Hỏi: Làm sao thầy tránh được sự nản lòng và yếm thế từ những nỗ lực thất bại trước đây?

Đáp: Để tránh thái độ tiêu cực, cấp quản lí phải chứng tỏ cam kết thực của họ với việc cải tiến qui trình bằng cách trao đổi thường xuyên với cấp dưới về mục đích và mong đợi của họ. Họ phải nhấn mạnh vào việc đạt tới cải tiến thực qua dữ liệu đo và thay đổi hệ thống thưởng. Qui trình thưởng mới có thể làm giảm sự yếm thế phát sinh ra do những nỗ lực trước đây đã đổ sập.

 

Hỏi: Cách hiệu quả nhất để triển khai các hoạt động cải tiến qui trình là gì? Làm sao thầy đảm bảo cam kết với bản kế hoạch hành động?

Đáp: Bản kế hoạch hành động dựa trên hiểu biết chung và việc học dần. Để làm điều này, bản kế hoạch hành động phải bao gồm chỉ đạo và mong đợi từ quản lí cấp cao (kế hoạch chiến lược). Nó phải nhận diện tất cả những điểm mạnh và yếu của tổ chức cũng như khuyến cáo cải tiến (kế hoạch chiến thuật) và nó phải bao gồm nhiều nhiệm vụ quản lí được để được triển khai (kế hoạch vận hành). Triển khai những nhiệm vụ này được quản lí, theo dõi và trao đổi tường minh. Mọi nhiệm vụ đều phải được xác định trong thực nghiệm kiểm soát (Xác định & Thử nghiệm) trước khi đưa vào trong tổ chức (Làm mịn & Thể lệ hoá). Mọi thay đổi phải bao gồm huấn luyện và đo. Khi những qui trình này lặp lại, việc học liên tục được xây dựng và cuối cùng được mở rộng trong toàn tổ chức (Thể lệ hoá)

 

Hỏi: Tại sao lại nói kĩ nghệ phần mềm là “kỉ luật”? Người làm phần mềm không cần cách tiếp cận quân sự ở đây. Cứ cho chúng tôi nhiều công cụ vào và chúng tôi sẽ chăm nom phần còn lại.

Đáp: Mọi công cụ trên thế giới sẽ không làm phần mềm nhanh hơn, tốt hơn, rẻ hơn, an toàn hơn, và tin cậy hơn. Nếu có công cụ như thế, công ti công cụ đó có lẽ đã làm ra nhiều tiền hơn bất kì công ti nào trên thế gian. Tôi tin vào câu ngạn ngữ, “Thằng ngu với công cụ — vẫn cứ là thằng ngu”.  Hay, như Albert Einstein đã nói: “Mọi phương tiện đều chứng tỏ là công cụ cùn nếu chúng không có đằng sau chúng một linh hồn sống”.

 

Hỏi: Tại sao hầu hết các tổ phần mềm đều thất bại? Người làm phần mềm có thể làm việc như một tổ được không?

Đáp: Phần bản chất của việc xây dựng một tổ tốt là chọn lọc người chơi. Trong thể thao, phần lớn các huấn luyện viên đều tuyển người chơi một cách cẩn thận nhưng nhiều người quản lí phần mềm lại không làm vậy. Họ đơn giản lựa thành viên tổ trên cơ sở người ngẫu nhiên có sẵn, và kĩ năng nào họ có. Vì họ không tính tới phong cách cá nhân, nhiều tổ thất bại trong thực hiện. Trong thể thao, huấn luyện viên cũng huấn luyện tổ thực hiện nhưng nhiều người quản lí phần mềm không biết cách huấn luyện hay nhận huấn luyện chính thức cho bản thân mình. Do bản chất không thấy được của phần mềm, tôi nghĩ người làm phần mềm cần kỉ luật nhiều hơn những người khác.

 

Hỏi: Tại sao chúng ta quan tâm đạt tới mức trưởng thành CMMI? Nhiều công ti nói mức CMMI cao và tin rằng họ tốt hơn công ti khác. Ý kiến của thầy là gì?

Đáp: Mức trưởng thành có thể được coi như việc đạt tới bằng cấp giáo dục. Mọi người tốt nghiệp đại học và nhận bằng cử nhân, thạc sĩ và tiến sĩ nhưng thực tế chính việc giáo dục mới là quan trọng, không phải mảnh bằng. Chúng ta tất cả đều chọn nhận mảnh bằng, đặt thông tin này vào lí lịch của mình, và có thể treo bằng lên tường. Vậy mà mảnh bằng đó là vô nghĩa cho cuộc hành trình và nỗ lực để có được nó. Tất cả chúng ta đều kiếm mảnh bằng hàn lâm nào đó và xứng đáng việc thừa nhận đạt tới “mức độ trưởng thành giáo dục” đặc biệt nào đó. Và cũng như một người có bằng tiến sĩ  vẫn không đảm bảo thành công hơn một người với bằng thạc sĩ, tổ chức CMMI mức 3 không đảm bảo gì thành công hơn tổ chức CMMI mức 2 nhưng nếu tôi có chọn lựa, tôi sẽ chọn Tiến sĩ và tổ chức CMMI mức 3.

—-English version——

 

Question: Why does organization need to improve their software process?

Answer: The quality of a product always depends on the quality of the process that creates the product. In order to produce high-quality software, the organization needs to improve its software process.

The Software Capability Maturity Model Integration (CMMI), developed at the Software Engineering Institute (SEI) at Carnegie-Mellon University (CMU), is a proven approach for managing the “process” for producing high quality software. It is a systematic and disciplined set of management methods designed to help organizations mature towards a higher level of process “capability ”  However, to do it right, besides improving the process, organizations must commit a considerable investment in its own people.

 

Question: Why so many software improvements failed? Even with the best resources and tools, many are still not making progress.

Answer: Most improvement efforts failed because the failure to address the “Unexpected” or the” Resistance to change”.  Even with the best technology, many organizations still failed, not because of the technology but the adoption of it. Unfortunately, many organizations often repeat this pattern over and over with every new technology introduces. Many people believe that new technology will change things but it does not happen because the organization fails to address the deeply held belief and behavior that hold organizational defensive behavior. People do not want to change unless they have to and this resistance to any change will eventually stop the change process and slowly destroy the energy and vitality of the change effort. In order to change, the organization can not rely on the technology that they want to bring in but must address the behavior aspect and it is the top management who should direct it with vision, goals, resources, incentives and actively monitor all changes.

 

Question: Our organization needs improvement but how do we start? We are engineers not manager and who will direct us to improve?

Answer: It is said that direction always starts at the top. This is true, of course, but I believe desire to improve can also be found at the bottom of an organization and at just about every place in between. To improve one must have a desire to change and this attitude can be found and must be practiced by employees at all levels of an organization. That is the only way in which an organization can get the most from managers and employees alike, achieve its strategic goals, fulfill the personal career aspirations of its people, and lay the groundwork for a quality processes and product.

Any engineer who recommends a solution to improve the software process is demonstrating leadership — given the parameters of his or her place in an organization — in the same way as a CEO who is launching an initiative to transform the entire corporation.

Everybody can improve something at any level and it doesn’t matter if you’re on the front line or the top line. If you are given an office with the powers of that office, what do you add to the office above and beyond those powers? Do you motivate people to improve? Do you bring excellence and vision to what ultimately is the objective of that office or even the whole company? Everyone can exercise improvement by being an individual contributor at any level of an organization.

 

Question: What does a fully mature software organization look like? What are the attributes of a CMMI level 4 or 5 organization?

Answer: In a fully mature organization (Level 4 and 5), quality is defined and predictable. Costs and schedules are always met. Software development processes are well defined and some are put under statistical control. Roles and responsibilities are clear, people are trained to do their roles and do them well. Software measurement discipline is always practiced. Process support technology is evaluated and used effectively. Training program is defined to promote talent growth and established a core competency. And success is always rides on the capability of the organization to handle challenge and individual talent flourishes within that.

 

Question: As a reward of being a successful manager, I was assigned the job of SEPG manager. I am not sure whether it is a reward or a punishment?

Answer: If process improvement is important to your boss then consider it a reward. After all is it critical to the success of your organization to reduce costs, increase productivity and quality? If your boss does not consider process improvement “Critical”, she probably assigned it to any available body, not to a successful project manager like yourself. Welcome to the process improvement journey.

 

Question: Our organization just starts to improve the software process but we do not want to make mistake like others. Do you have any suggestions?

Answer: Many organizations do made mistakes when improving their software process. Some are due to lack of experience; others are the result of resistance to change. Naturally mistakes can be avoided by following the lessons learned from others. Here are few tips to avoid these mistakes:

1.   Always define reasonable, measurable, and achievable improvement goals.

2. Improvement goals must be tied to business objectives.

3. Plan for adequate resources, especially skilled resources.

4. Treat process improvement as a project, all improvement efforts must be planned and tracked to closure.

5. Do not waste time for a robust solution but concentrate on many small solutions.

6. Ensure all levels of management are involved.

7. Ensure every solution must be piloted to ensure it works properly before use them across organizations (Institutionalization).

8. Do not try to define the organization software standard process (OSSP) too early.

9. Establish a measurement baseline as soon as possible.

10. Know when you need to get help and ask for it. Do not try to do it all by yourself.

 

Question: Our management is planning to compare data between several software groups and looking for the lowest ranking for “corrective action”. Is it what measurement is all about?

Answer: To have a meaningful metrics, data collection must be approached with great care and data must be defined in advance before collection begins. When different groups collecting data and do not use the same definitions, the results are not comparable, even compare them may make sense at some high management level. The tendency to compare groups and put pressure on those with low ranking is an unfortunate and misuse of measurement data. I do not think that two groups are similar by any simple measures. The variation in task complexity caused by different product types, platforms, customers, environment can be significant. Productivity data is meaningless unless explicitly defined; for example, the number of lines of code per month can vary significantly depending on the interpretation of the parameters. I believe the code count should include only new and changed code of all shipped instructions.

I strongly believe that data must NOT be used to compare groups, projects or individuals. The sole purpose of measurement is to illuminate the product being built and to provide an informed basis for improving the process. When using for other purposes, the data itself will deteriorate.

Question: Why users do not trust developers? Why can’t they work as partners?

Answer: I believe it is the credibility issues. Many software developers tend to set themselves apart from their customers as technology specialist without understand that they belong to a supporting function and not quite an equal to the customer.

An equal partner requires trust and respect, and to do that, software developers must focus on creating a reputation of trustworthiness, before emphasize on their expertise. To earn the trust of the customer, software developers must learn about the customer business, their processes, their needs, their requirements, their costs, etc. Do not use your technical jargon that customer do not understand, that always creates mistrust. Do not rush to suggest technical solutions but try to help them explore non-technology options first. Only by working together, we can find the common ground and with time, establish a true equal partnership.

 

Question: How do you avoid the discouragement and cynicism from previous failed attempt?

Answer: To avoid the negative attitude, management must demonstrate their real commitment to process improvement by frequently communicate to their subordinate about their goals and expectations. They must insist on achieving real improvement via measurement data and change the rewarding system. A new reward process can reduce the cynicism generated by prior efforts that fell flat.

 

Question: What is the most effective way to deploy process improvement activities? How do you ensure commitment to an Action plan?

Answer: Action plan is committed based on a common understanding and gradual learning. To do this, action plans must consist direction and expectations from senior management (Strategic plan). It must identify all the strengths and weaknesses of an organization as well as recommendations to improve (Tactical plan) and it must consists several manageable tasks to be deployed (Operational plans). Deployment of these tasks are explicitly managed, tracked, and communicated. All tasks must be defined in control experiments (Define & Pilot) before introducing into the organization (Refine & Institutionalize). All changes must include training and measurements. As these process iterate, the learning is continuously built and eventually extended throughout the organization (Institutionalization)

 

Question: Why advocate a software engineering “disciplines”? Software people do not need a militant approach here. Give us more tools and we will take care of the rest.

Answer: All of the tools in the world will not make software faster, better, cheaper, safer, and more reliable. If there is such a tool, that tool company would probably make more money than any company on earth. I do believe the saying, “A fool with a tool — is still a fool”.  Or, as Albert Einstein had said: “All means prove but blunt instruments if they have not behind them a living spirit”.

Question: Why most software teams failed? Can software people works as a team?

Answer: The essential part of building a good team is picking the players. In sport, most coaches do select players carefully but many software managers do not. They simply select team members on the basis of who happens to be available, and what skills do they have. Since they do not take into account the individual styles, many teams fail to perform. In sport, coaches also trained the team to perform but many software managers do not know how to train or receive formal training themselves. Due to the intangible nature of software, I think software people need more disciplines than others.

 

Question: Why do we care about achieving a CMMI maturity level? Many companies claimed a high CMMI levels and believe that they are better than others. What is your opinion?

Answer: Maturity levels may be thought of as achieving an educational degree. People graduate from university and receive a degree such as BS, MS, and Ph.D but actually it is the education that is important, not the piece of paper. We all elect to receive the piece of paper, place the information on our resumes, and maybe hang the diplomas on the wall. Yet the piece of paper is insignificant to the journey and the efforts to obtain it. We all earned some academic degree and deserve the recognition of achieving a particular “educational maturity level.” And just like a person with a Ph.D isn’t guaranteed to be more successful than a person with a Master’s degree, a CMMI level 3 organization isn’t guaranteed to be more successful than a CMMI level 2 organization but if I have a choice, I would choose the Ph.D and CMMI level 3 organization.