Hỏi: Tại sao chúng tôi cần tập trung vào cải tiến phần mềm, điều là chức năng “hỗ trợ” khi doanh nghiệp của chúng tôi là chế tạo?

Đáp: Vì phần mềm được bắt đầu như chức năng “hỗ trợ” cho chế tạo sản phẩm về máy bay hay ô tô, vài người tưởng nó không quan trọng. Tuy nhiên, mọi sự đã thay đổi rồi. Ngày nay phần mềm kiểm soát máy bay, lái xe và tác động vào gần như mọi khía cạnh của cuộc sống chúng ta. Nó đã tiến hoá từ chức năng “hỗ trợ” thành một phần quan trọng của doanh nghiệp. Tuy nhiên, không giống như các sản phẩm khác, phần mềm nói chung có nhiều vấn đề hơn như chỉ là lỗi. Lỗi 10% được coi là “bình thường” (tức là 100 lỗi trên 1000 dòng mã). Nếu chúng ta không nghiêm chỉnh về chất lượng và độ tin cậy phần mềm, nó có thể tác động nghiêm trọng vào doanh nghiệp và vào cuộc sống chúng ta. Chúng ta không nên chờ đợi cho tới khi cái gì đó lớn lao xảy ra, thách thức doanh nghiệp của mình phải làm cái gì đó về nó.

Trong các lĩnh vực khác như dược phẩm hay y tế nơi mạng sống con người bị lâm nguy, mọi công nhân đều được huấn luyện làm việc theo các chuẩn và thủ tục được thiết lập rõ. Bất kì vi phạm hay xâm phạm nào vào chúng cũng đều có thể làm chết người. Tuy nhiên, trong phần mềm, phần lớn người lập trình lại không được huấn luyện để tuân theo qui trình, họ lạio được phép làm việc theo qui tắc riêng của họ. Nhiều người bắt đầu với những yêu cầu mơ hồ và thường xuyên thay đổi nhưng lại được mong đợi chuyển giao sản phẩm cuối cùng theo lịch biểu đã ấn định. Điều đó nghĩa là những người này phải thiết kế, viết mã, kiểm thử và sửa phần mềm của họ tương ứng với một môi trường hỗn độn và thường xuyên thay đổi trước khi tích hợp chúng vào sản phẩm được chế tạo như ô tô, tàu thuyền hay máy bay.

Khi mọi người làm việc dưới sức ép, họ không tránh khỏi việc phạm sai lầm. Trung bình, người lập trình có kinh nghiệm phạm 1 sai lầm cứ mỗi 10 dòng mã lệnh. Họ sửa được một nửa số lỗi khi dịch mã và sửa nhiều hơn trong kiểm thử. Tất nhiên, cách tiếp cận mong muốn là sửa tất cả các lỗi trước khi chuyển giao cho khách hàng nhưng thông thường người lập trình bị hết thời gian và không thể sửa được lỗi cho nên đằng nào phần mềm được đưa ra cho khách hàng cũng vẫn có nhiều lỗi. Một sự kiện đã được chứng minh là lỗi được nhận diện càng về sau, việc sửa chúng càng tốn kém hơn, cộng thêm là càng có thể có vấn đề gây ra ngắt quãng ở việc hợp dịch cuối cùng của sản phẩm. Với thực hành hiện thời, các chương trình được kiểm thử rồi có thể vẫn còn có lỗi; và nhiều lần, máy tính sẽ chạy với phần mềm vẫn bị lỗi. Vấn đề sẽ vẫn như vậy chừng nào một tập các hoàn cảnh còn chưa nảy sinh làm lỗi xuất hiện và có thể gây hại cho kết quả.

Người lập trình tốt sẽ tiến hành kiểm điểm mã trước khi kiểm thử nhưng trong môi trường ngày nay, loại kỉ luật này được biết tới nhưng hiếm khi được thực hành. Nhiều người lập trình không được huấn luyện trong các cuộc kiểm điểm kĩ nghệ phần mềm hay qui trình giám định và nhiều người quản lí phần mềm không được huấn luyện để hiểu các kỉ luật này. Phần lớn những người lập trình vẫn không biết tại sao họ phải lập kế hoạch và quản lí công việc của mình theo qui trình được xác định. Họ biện luận rằng “lập kế hoạch làm giảm năng suất” và “kỉ luật hại canh tân.” Phần lớn khủng hoảng là do thiếu lập kế hoạch và không tuân theo qui trình có kỉ luật. Khi người quản lí chỉ hội tụ vào lịch biểu, họ ngụ ý rằng chẳng cái gì khác là quan trọng. Rất ít người quản lí hỏi về chất lượng, tính khả dụng, tính năng suất, hay tuân thủ qui trình. Một khi chương trình qua được kiểm thử và chuyển giao cho khách hàng, phần lớn người lập trình không biết điều gì xảy ra cho chương trình, liệu nó làm việc hay hỏng. Phần lớn những người lập trình không biết phần mềm bị lỗi sẽ tạo ra bao nhiêu thiệt hại hay ý kiến của khách hàng là quan trọng đến đâu cho doanh nghiệp. Phần lớn người lập trình không được huấn luyện về phương pháp chất lượng. Khiếm khuyết bị coi là “lỗi” nhưng chúng thực sự không phải là lỗi, chúng là khiếm khuyết và chương trình có khiếm khuyết là mang tính khiếm khuyết. Và vì khiếm khuyết là do người lập trình đưa vào, người lập trình phải loại bỏ chúng. Để người lập trình loại bỏ khiếm khuyết, họ phải được huấn luyện đúng để tuân theo qui trình được xác định. Việc huấn luyện kĩ nghệ phần mềm cung cấp cho tổ chức kỉ luật này để nâng cao năng lực của họ sản xuất ra phần mềm với chi phí hợp lí và với ít khiếm khuyết hơn. Để cải tiến việc chế tạo hay bất kì doanh nghiệp nào, điều có nghĩa là bắt đầu với một trong những phần mấu chốt khác: Phần mềm.

Hỏi: Công ti chúng tôi nhỏ, chúng tôi không có ý tưởng nào về chúng tôi dựa vào đâu ở mức CMMI nhưng cứ giả định rằng chúng tôi đang ở mức thấp nhất. Chúng tôi phải làm cải tiến cái gì cho tổ chức CMMI mức 1?

Đáp: Hoạt động quan trọng nhất cần bắt đầu là học cách cải tiến ước lượng dự án (tức là kích cỡ, tài nguyên, lịch biểu v.v.). Bạn cần ước lượng dự án của bạn lớn mức nào? Bạn cần bao nhiêu người cho dự án và sẽ mất bao lâu để hoàn thành dự án này? Ước lượng là nền tảng của lập kế hoạch dự án phần mềm, điều rất mấu chốt cho tổ chức CMMI mức 1. Dựa trên dữ liệu tôi đã thu thập trong nhiều năm qua, phần lớn các dự án phần mềm thất bại bởi vì hoặc họ làm ước lượng lịch biểu sai hoặc có quá nhiều thay đổi trong yêu cầu. Cả hai điều này đều có thể được dõi về việc ước lượng và lập kế hoạch dự án kém. Vì các ước lượng chính xác tuỳ thuộc vào dữ liệu lịch sử, tổ chức phải thu thập các dữ liệu này: Bạn đã lập kế hoạch gì so với điều thực tế đã xảy ra (tức là lập kế hoạch so với thực tại), phân tích chúng để hiểu tại sao có sai lệch giữa dữ liệu kế hoạch và dữ liệu thực tế và lưu giữ chúng trong cơ sở dữ liệu cho tham chiếu tương lai. Chỉ khi tổ chức đã thu được khả năng ước lượng chính xác để thực hiện dự án tương ứng, họ có thể làm các tiến bộ thêm. Mục tiêu quan trọng nhất của tổ chức CMMI mức 1 là đạt tới khả năng đáp ứng nhất quán lịch biểu, chi phí và cam kết chức năng của dự án cho khách hàng trước khi tập trung vào các hoạt động cải tiến khác.

 

Hỏi: Chức năng của Đảm bảo chất lượng phần mềm (SQA) là gì và khác biệt giữa SQA và Nhóm qui trình kĩ nghệ phần mềm (SEPG) là gì?

Đáp: Để đảm bảo chất lượng của sản phẩm phần mềm, phần lớn các tổ chức thực hiện hai chức năng chính:

(1) Đảm bảo sản phẩm: Giám định sản phẩm qua toàn bộ vòng đời để đảm bảo rằng sản phẩm đúng được xây dựng tương ứng với đặc tả được yêu cầu. Điều này bao gồm thực hiện kiểm điểm, giám định, theo dõi yêu cầu, và kiểm thử sản phẩm phần mềm.

(2) Đảm bảo qui trình: Giám định qui trình trong toàn bộ vòng đời để đảm bảo rằng dự án đang tuân theo qui trình được xác định, điều được nhận diện trong kế hoạch dự án. Điều này bao gồm kiểm định trong qui trình và kiểm điểm qui trình hậu kì.

SQA thực hiện cả hai chức năng trên, cũng như báo cáo về bất kì vấn đề nào không giải quyết được cho cấp quản lí. Về căn bản, tổ chức bắt đầu từ đảm bảo sản phẩm (tức là kiểm điểm, giám định, và theo dõi yêu cầu). Khi các hoạt động này được thể lệ hoá tốt rồi, SQA sẽ tập trung vào tuân thủ qui trình, bắt đầu với kiểm điểm yêu cầu, và đảm bảo rằng việc lập kế hoạch dự án là đầy đủ. SQA phải đảm bảo rằng các qui trình đã được thoả thuận (được nhận diện trong kế hoạch dự án) được tuân theo và rằng sự sai biệt được báo cáo cho cấp quản lí trong toàn thể vòng đời.

SEPG là khác với SQA ở chỗ nó hướng dẫn tổ chức trong nỗ lực cải tiến qui trình. Điều này bao gồm việc tiến hành thẩm định để xác định các miền cần cải tiến và thực hiện các hành động đó để cải tiến năng lực của toàn tổ chức (cả kĩ thuật và phi kĩ thuật). Thẩm định của SEPG chỉ dành riêng cho cải tiến qui trình, đó là khác với kiểm định qui trình của SQA kiểm tra về tuân thủ; do vậy, SQA và SEPG là hai chức năng tách biệt.

 

Hỏi: Mối quan hệ giữa CMMI và P-CMM là gì? Tại sao tạo ra mô hình khác cho Con người?

Đáp: Với sự giúp đỡ của CMMI, nhiều tổ chức đã thực hiện những cải tiến có nghĩa trong thực hành phần mềm. Ích lợi tài chính và hiệu năng của những cải tiến này cũng được ghi lại rõ trong văn đàn (như các nghiên cứu của Raytheon, Hughes, Boeing, City Bank, và Motorola). Tuy nhiên, nhiều tổ chức trong số này đã phát hiện ra rằng để liên tục cải tiến họ phải thay đổi cách họ quản lí con người nhưng những thay đổi đó lại không được tính tới trong CMMI.

Dựa trên dữ liệu tôi đã thu thập, phần lớn các chương trình cải tiến đều nhấn mạnh phần lớn vào qui trình và công nghệ chứ ít tập trung vào con người. Ngày nay, nhiều tổ chức phần mềm đã không coi phát triển người của họ là nghiêm chỉnh như họ đã tiếp cận tới việc phát triển qui trình hay công nghệ của họ. Dữ liệu từ các tổ chức trưởng thành cao chỉ ra rằng việc tiến bộ liên tục của họ yêu cầu cải tiến cách họ quản lí mọi người. Một số tổ chức thậm chí đã thấy việc duy trì cải tiến qui trình là khó nếu họ bị nhiều vấn đề con người nghiêm trọng như luân chuyển nhân viên quá nhiều.

Để đưa ra hướng dẫn cho tổ chức muốn phát triển tài năng phần mềm, Viện Kĩ nghệ Phần mềm tại Đại học Carnegie Mellon đã phát triển một mô hình có tên là Mô hình trưởng thành năng lực con người – People Capability Maturity Model (P-CMM) dựa trên những thực hành tốt nhất trong lĩnh vực tài nguyên người và phát triển tài năng. P-CMM cung cấp cho tổ chức những hướng dẫn về cách kiểm soát thực hành tài nguyên của họ và thiết lập văn hoá về xuất sắc kĩ nghệ. P-CMM có thể dễ dàng được tích hợp với CMMI để cải tiến tổ chức tổng thể.

 

Hỏi: Chúng tôi có nên dùng mô hình lập lịch biểu dựa trên cách đo hay mô hình chi phí cho cải tiến qui trình không?

Đáp: Tôi muốn lựa chọn dứt khoát mô hình lập lịch biểu dựa trên cách đo hơn là mô hình chi phí. Theo kinh nghiệm của tôi, ước lượng chính xác hình thành nên cơ sở khách quan cho lập kế hoạch chi tiết và theo dõi tiến bộ là điều bản chất cho thành công của dự án, tính không có khả năng kiểm soát ước lượng là vấn đề phát triển phần mềm then chốt, vấn đề mà mô hình chi phí không thể giải được.
Khái niệm then chốt trong mô hình lập lịch biểu dựa trên cách đo là ở chỗ phần mềm với những đặc trưng ứng dụng, qui trình, công nghệ, phương pháp và tài nguyên tương tự sẽ chia sẻ các kinh nghiệm tổ chức tương tự. Những kinh nghiệm được nắm bắt này có thể được dịch thành các quan hệ đo tương tự, các thuật toán và các mô hình tham biến chuyên sản phẩm. Tất cả những kinh nghiệm đó được dùng để sinh ra các ước lượng, xây dựng kế hoạch và tạo ra tuyến cơ sở cho các dự án tương lai.

 

Hỏi: Tôi là người quản lí mới của một dự án chạy không tốt. Người quản lí trước đã ra đi trong thất vọng vì nhóm không phải là tổ, mọi người làm điều họ muốn làm nhưng chẳng chịu trách nhiệm về cái gì. Làm sao tôi thay đổi được họ thành tổ có hiệu quả?

Đáp: Có năm cấu phần quan trọng của tổ hiệu quả:
1) Mục đích của tổ: Ý thức của tổ về mục đích và chiều hướng.

2) Vai trò của tổ: Hiểu biết về cách công việc được phân công.

3) Qui trình của tổ: Thủ tục vận hành, cách thức tổ tiến hành công việc của mình

4) Quan hệ tổ: Cách các thành viên tổ làm việc cùng nhau.

5) Quyền lãnh đạo tổ: Năng lực của tổ điều phối và gióng thẳng các qui trình tổ và mối quan hệ.

Mọi tổ đều có thể được phát triển trong bốn giai đoạn:

1) Hình thành: Khi các thành viên tổ làm quen lẫn nhau và thiết lập qui tắc cho tổ vận hành. Tuy nhiên, vấn đề là nhóm có thể đi vào “chu trình tranh cãi vô tận” và không làm cho công việc được thực hiện.

2) Bão tố: Khi các thành viên tổ “đụng độ” qua thách thức mà nhóm phải đối diện.
Nguy hiểm: Sự thù địch bùng phát và tạo ra thù oán đeo bám tổ. Mọi người sẽ cố gắng chiếm quyền lãnh đạo vào tạo ra cảm giác xấu.

3) Bình thường: Khi tổ đi theo hướng cộng tác, cam kết, cố kết.

Nguy hiểm: Tổ sẽ cộng tác quá nhiều và bỏ qua giải pháp thực

4) Hoạt động: Khi tổ thực muốn làm điều nó đã lập hiến chương để làm.

Nguy hiểm: Tổ có thể không muốn rời ra sau khi vấn đề đã được giải quyết và liên tục làm mịn vấn đề vượt quá giới hạn chấp nhận được.

Tôi thực sự tin tổ của bạn cần việc huấn luyện làm việc tổ bằng không thì dự án của bạn sẽ không đạt được mục đích mà cấp quản lí lập ra cho họ.

Hỏi: Vì dự án của chúng tôi nhỏ (1-5 người) liệu có thể người quản lí dự án kiêm luôn chức năng Đảm bảo chất lượng phần mềm (SQA) thay vì thuê ai đó khác được không?

Đáp: Không, bạn không nên làm điều đó. Người SQA độc lập đánh giá “một cách khách quan” sản phẩm và qui trình để phát hiện các vấn đề không tuân thủ. Người quản lí dự án không thể là khách quan như SQA độc lập được. Chẳng hạn, điều gì xảy ra nếu người quản lí dự án không sửa các vấn đề không tuân thuur mà người đó chịu trách nhiệm? Đây là xung đột quyền lợi và làm sao những vấn đề này có thể leo thang lên quản lí cấp cao được? Với dự án nhỏ, giải pháp tốt nhất là phân công ai đó bên ngoài dự án thực hiện chức năng SQA. Bạn có thể có một kĩ sư hay người lập trình lấy từ dự án khác bên trong cùng tổ chức  để thực hiện chức năng này.

 

Hỏi: Vì có nhiều mô hình CMM bên trong khuôn khổ CMMI như People-CMM, CMM Thu nhận, CMM Dịch vụ, chúng tôi có nên thiết lập vào nhóm cải tiến, mỗi nhóm tập trung vào một mô hình đặc thù không?

Đáp: Một trong những khía cạnh ích lợi của Mô hình trưởng thành năng lực tích hợp Capability Maturity Model Integration (CMMI) là ở chỗ tất cả các cấu phần đều có chung cùng kiến trúc nền tảng. Ý định dùng kiến trúc chung cho mọi mô hình là để tạo khả năng cho tổ chức thiết lập kết cấu nền được hỗ trợ, được kinh nghiệm mà có thể áp dụng cho bất kì cấu phần CMM nào vào thời điểm thích hợp cho tổ chức đó. Tạo ra kết cấu nên hỗ trợ tách rời cho từng mô hình là phí thời gian và tài nguyên. Kết cấu nền SEPG là một tổ chức đã có được huấn luyện, hiểu nhu cầu thay đổi, và đã phát triển uy tín về thực hiện thành công CMMI. SEPG có thể phối hợp và quản lí những thay đổi bởi bất kì CMM nào.

———English version————

 

CMMI-9

Question: Why do we need to concentrate on improving software which is a “support” function when our business is in manufacturing?

Answer: Since software started as a “support” function for manufacturing products of an airplane or a car, some people think it is not important. However, things have changed. Today software controls airplane, drives cars and impacts almost every aspect of our life. It has evolved from a “support” function into an important part of the business. However, unlike other products, software generally has more problems such as defects. A 10% defect is considered “normal” (that’s 100 defects per 1000 lines of code). If we are not serious about software quality and reliability, it may seriously impact our business and our life. We should not wait until something dramatic happens that challenges our business to do something about it.

In other fields such as medicine or health care where people lives are at stake, all workers are trained to work in accordance with well-defined standards and procedures. Any violation or infractions could kill people. However, in software, most programmers are not trained to follow a process but allowed to work according to their own rules. Many started with vague and constantly changing requirements but are expected to deliver a final product within a fixed schedule. That means these people have to design, code, test, and fix their software according to a chaotic and constantly changing environment before integrated them into the manufactured product such as a car, a boat or an airplane.

When people work under stress, they inevitably make mistakes. On the average, experienced programmers make a mistake every 10 lines of code. They fix about half of that when compiling the code and even more during test. Of course, the desired approach is to fix all defects before delivery to the customer but usually programmers run out of time and can not fix them so the software is released to customer with many defects anyway. It is a proven fact that the later a mistake is identified, the more expensive it is to fix, plus it is more likely that the problem caused a disruption in the final assembly of the product. With current practices, tested programs can still have defects; and many times, computers will run with defective software. It is not until a specific set of circumstances arise that a defect appears and possibly harms the results.

A good programmer will conduct code reviews before testing but in today’s environment, this kind of discipline is known but seldom practiced. Many programmers are not trained in software engineering reviews or inspection process and many software managers are not trained to understand these disciplines. Most programmers still do not know why they should plan and manage their work according to a defined process. They argue that “planning reduces productivity” and “discipline harms innovation.” Most crises are caused by the lack of planning and not following a disciplined process. When managers only focus on schedules, they are implying that nothing else is important. Very few managers ask about quality, usability, productivity, or process compliance. Once a program passes testing and delivers to the customer, most programmers do not know what happens to the program, whether it works or fails. Most programmers do not know how much damage a defective software would create or how much customer’s opinions are important to the business. Most programmers are not trained in quality methods. Defects are treated as “bugs” but they really aren’t bugs, they’re defects and programs with defects are defective. And since defects are injected by programmers, programmers must remove them. In order for programmers to remove defects, they must be trained properly to follow a defined process. The software engineering training provides organizations with this discipline to improve their capability to produce software at a reasonable cost and with fewer defects. To improve the manufacturing or any business, it makes sense to start with one of the most critical parts: Software.

 

Question: Our company is small, we have no idea where we are based on the CMMI level but assume that we are at the lowest level. What should we do to improve a CMMI level 1 organization?

Answer: The most important activity to start is learning how to improve the project estimates (i.e. Size, resources, schedule etc.). You need to estimate how big is your project? How many people that you need for the project and how long will it take to complete the project? Estimate is the foundation of software project planning which is very critical for CMMI level 1 organization. Based on data that I have collected in past several years, most software projects failed because of either they have wrong schedule estimate or have too many changes in requirements. Both of them can be traced to poor project estimating and planning. Since accurate estimates depend on historical data, organization must collect these data: What you have planned versus what actually happened (i.e. planned versus actuals), analyzes them to understand why there were variations between planned data and actual data and stores them in a database for future references. Only when the organization has acquired the ability to estimate accurately to execute the project accordingly, they can make further advances. The most important objective of a CMMI level 1 organization is achieving the ability to consistently meet project’s schedule, cost, and functional commitments to customers before focusing on other improvement activities.

 

Question: What is the function of Software Quality Assurance (SQA) and what is the difference between SQA and Software Engineering Process Group (SEPG)?

Answer: To ensure the quality of software products, most organizations perform two major functions:

(1) Product assurance: Inspect the product throughout the life cycle to ensure that the correct product is being built according to the required specifications. This includes performing product reviews, inspections, requirements traceability, and tests on the software products.

(2) Process assurance: Inspect the process throughout the life cycle to ensure that the project is following the defined process, which is identified in the project plan. This includes in-process-audits and post-mortem process reviews

SQA performs both of the above functions, as well as reports any unresolved problems to management. Typically, organization begins with product assurance (e.g., reviews, inspections, and trace requirements). When these activities are well institutionalized, SQA will concentrate on process compliance, beginning with requirement reviews, and ensure that project planning is complete. SQA must ensure that the agreed upon processes (identified in the project plan) are being followed and that discrepancies are reported to management throughout the life cycle.

SEPG is different from SQA in that it leads the organization in process improvement efforts. This includes conducting assessments to determine areas for improvement and executing those actions to improve the capability of the entire organization (technical and non-technical). A SEPG assessment is strictly for process improvement, which is different from SQA process audit to check for for compliance; thus, SQA and SEPG are two separate functions.

 

Question: What is the relationship between a CMMI and P-CMM? Why create another model for People?

Answer: With the help of the CMMI, many organizations have made significant improvements in their software practices. The financial and performance benefits of these improvements are well documented in literature (i.e. Raytheon, Hughes, Boeing, City Bank, and Motorola studies). However, many of these organizations discovered that in order to continue their improvement they must change the way they manage people but theses changes are not accounted for in the CMMI.

Based on data that I have collected, most improvement programs have emphasized mostly on process and technology but few focus on people. Today, many software organizations have not take the development of their people as seriously as they approached the development of their processes or technology. Data from high maturity organizations indicated that their continued progress required improving in the way they manage people. Some organizations have even found sustaining process improvement difficult if they were suffering severe people problems such as excessive turn-over of their employees.

To provide guidance to organization that want to develop software talent, the Software Engineering Institute at Carnegie Mellon University has developed a model called the People Capability Maturity Model (P-CMM) based on the best practices in the field of human resources and talent development. The P-CMM provides organization with guidance on how to gain control over their resources practices and establishing a culture of engineering excellence. The P-CMM can easily be integrated with the CMMI for overall organization improvement.

 

Question: Should we use a Metric-based scheduling model or a Cost model for process improvement?

Answer: I would definitely select the metric-based scheduling model over the cost model. Based on my experience, accurate estimates form the objectives basis for the detailed planning and progress tracking that are essential to project success, the inability to control estimates is the key software development problem, a problem that the cost model can not resolve.

The key concept in metric-based scheduling model is that software with similar application, process, technology, method, and resource characteristics will share similar organizational experiences. These captured experiences can be translated into similar metric relationships, algorithms, and product-specific parametric models. All of which are used to generate estimates, develop plans and create baselines for future projects.

 

Question: I am a new manager of a dysfunctional project. The former manager left in frustration since the group is not a team, people do what ever they want to do but not responsible for anything. How do I change them into an effective team?

Answer: There are five important components of an effective team:

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.

Any team can be developed in four stages:

1) Forming: When team members get to know each other and establish the rule in which the team will operate. However, the issue is the group may go to an “infinite loop of debating” and not getting work done.

2) Storming: When team members “collide” over the challenges facing the group.

Danger: Hostility breaks out and creates animosity that lingers with the team. People will try to assume leadership and create bad feeling.

3) Norming: When team move toward cooperation, commitment, cohesion

Danger: Team will cooperate too much and pass up the real solutions

4) Performing: When the team does want to do what it was chartered to do

Danger: The team may not want to quit after problems has been solved and continue to refine the problem past acceptable limit.

I do believe your team needs teamwork training or else your project will not achieve the goal that management set for them.

 

Question: Since our projects are small (1-5 people) is it possible that project manager could perform the Software Quality Assurance (SQA) function instead of hiring somebody else?

Answer: No, you should not do that. An independent SQA “objectively” evaluates products and processes to detect non-compliance issues. A project manager is not likely to be as objective as an independent SQA. For example, what happens if the project manager does not fix the non-compliance issues that he or she is responsible for? This is a conflict of interest and how would these issues get escalated to senior management? On a small project, the best solution is to assign someone outside the project to perform the SQA function. You can have an engineer or programmer from another project within the same organization to perform this function.

 

Question: Since there are several CMM models within the CMMI framework such as People-CMM, Acquisition CMM, Service CMM should we establish several improvement groups, each focus on a particular model?

Answer: One of the beneficial aspects of the Capability Maturity Model Integration (CMMI) is that all of the components share the same fundamental architecture. The intent of using a common architecture for all models is to enable an organization to establish an experienced, supported infrastructure that can apply any of the CMM components at the appropriate time for that organization. To create separate support infrastructures for each model is a waste of time and resources. The SEPG infrastructure is the organization that has received the training, understands the need for changes, and has developed a reputation for successful implementation of the CMMI. The SEPG can coordinate and manage changes by any CMM.