Tải bản đầy đủ (.pdf) (11 trang)

CMMI 2

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (103.05 KB, 11 trang )

CMMI-2

CMMI-2
Bởi:
Ngô Trung Việt
John Vu
Hỏi: Tôi đã đọc một báo cáo nói rằng trên 70% tổ chức được đánh giá dùng CMMI đều
thất bại khi thực hiện kế hoạch hành động cải tiến và chỉ 14% tổ chức đã thực hiện việc
cải tiến của họ trong một năm, khá đủ để tiến hành việc đánh giá lại, chẳng thấy thay đổi
hay cải tiến gì cả. Tại sao nhiều cải tiến qui trình lại thất bại thế?
Đáp: Tôi tin nhiều tổ chức thất bại bởi vì họ không tuân theo các pha cải tiến của
mô hình IDEAL (Initiating – Khởi đầu, Diagnosing-Chẩn đoán, Establishing-Thiết lập,
Acting-Hành động, và Leveraging-Thúc bẩy). Phần lớn đã bỏ qua pha Khởi đầu (Pha
quan trọng nhất hội tụ vào việc thu được cam kết của cấp quản lí và thiết lập nhóm để
cải tiến qui trình) và đi thẳng vào pha Chẩn đoán (Tiến hành đánh giá). Không có cam
kết của cấp quản lí, mọi sự sẽ thất bại không đưa mọi người vào thực hiện kế hoạch hành
để giải quyết các vấn đề gay cấn.
Tôi cũng tin rằng nhiều tổ chức thất bại bởi vì họ không có kĩ năng và kinh nghiệm cần
thiết để thực hiện hành động cải tiến. Nhiều người nghĩ họ biết cách làm mọi sự xảy ra
vì họ đã đọc sách, tham dự các xê mi na và có khả năng nói một cách thông minh về
chủ đề này. Cải tiến qui trình là về thay đổi và thay đổi là gian nan, bạn không thể thay
đổi được ai đó chừng nào bạn chưa thay đổi bản thân mình trước. Nếu bạn không dịch
chuyển cái nhìn của mình lên mức cao hơn bạn không thể trợ giúp được cho bất kì ai
dịch chuyển cái nhìn của họ. Đó là lí do tại sao đôi khi người tư vấn có thể có ích ở đây.
Dựa trên kinh nghiệm của tôi, sau đây là một số lí do tại sao việc cải tiến qui trình thất
bại, theo thứ tự ưu tiên:
1)

Không có cam kết dài hạn của cấp quản lí

2)



Thiếu kinh nghiệm và kĩ năng trong cải tiến qui trình

3)

Không có tầm nhìn rõ ràng về kết quả mong muốn

4)

Kế hoạch hành động quá tham vọng

5)

Không có phản hồi định lượng về tiến bộ (không đo)

1/11


CMMI-2

6)

Diễn giải sai về CMMI

7)

Quá nhiều hội họp và thảo luận mà không hành động

8)


Văn hoá sai (thất bại nhiều lần trong quá khứ, sợ thay đổi)

9)
Người sai trong SEPG (quá nhiều thời gian dành cho làm tài liệu và không có
thời gian để thực hiện)
10)

Không phải tất cả mọi người đều tham gia vào quá trình thay đổi

Hỏi: Bao nhiên ngân sách cần dành cho việc cải tiến qui trình CMMI? Làm sao thầy
chia nhỏ và biện minh cho nó được?
Đáp: Cải tiến qui trình điển hình là vào quãng 3%-5% ngân sách hàng năm. Nó có vẻ
nhiều nhưng đó là đầu tư mà, nếu được thực hiện thành công, có thể đem lại lãi đáng kể.
Đây là việc chia nhỏ ngân sách:
1) Bước đầu tiên cần bắt đầu là nhận biết về các hoạt động cải tiến. Mọi người bao giờ
cũng muốn biết lí do (tại sao), qui trình (thế nào), mục tiêu (cái gì) và lộ trình nào (khi
nào, ở đâu) mà họ phải theo. Cách tốt nhất để làm cho tất cả mọi người trong tổ chức
nhận biết về các hoạt động là đào tạo họ về khuôn khổ CMMI.
“Nhập môn về CMMI” là lớp học được thiết kế cho hoạt động này. Xét tới kích cỡ của
tổ chức điển hình có xấp xỉ 300 – 600 người, và từng lớp sẽ có xấp xỉ 60 người. Bạn cần
lên lịch biểu ít nhất từ 5 tới 10 lớp cho tổ chức và cũng thiết lập nên một lớp đặc biệt
cho cấp quản lí. (Họ cần biết về CMMI nữa.) Có chi phí liên kết với việc làm cho tất cả
mọi người học một lớp; nhưng dựa trên dữ liệu tôi thu thập được từ 10 năm qua, đây là
đầu tư rất tốt.
2) Bước thứ hai là thiết lập một nhóm toàn thời chuyên dành cho việc hỗ trợ hoạt động
cải tiến. Cái tên thông thường nhất của nhóm này là Nhóm Qui trình Kĩ nghệ Phần mềm
– Software Engineering Process Group, hay SEPG. Các thành viên của SEPG cũng cần
được huấn luyện thêm để làm việc của họ, điều này cũng đòi hỏi tổ chức phải chi tiêu
thêm ngân sách.
3) Bước thứ ba là trao đổi về mọi hoạt động cải tiến, thành tựu, độ đo, mục đích và mục

tiêu. Điều này nên được thực hiện trên cơ sở đều đặn để giữ cho cấp quản lí và mọi
người trong tổ chức được thông tin. Quản lí thay đổi yêu cầu trao đổi tốt về thay đổi,
thừa nhận tiến bộ đã đạt được, và đo xem tổ chức đã cải tiến được đến đâu so với mục
đích của mình. Hoạt động này cũng đòi hỏi thời gian và nỗ lực.
Cũng có chi phí liên kết với việc đánh giá, thiết lập kế hoạch hành động cải tiến, và thực
hiện các hoạt động cải tiến. Phần lớn mọi người trong tổ chức sẽ tham gia vào những
2/11


CMMI-2

hoạt động cải tiến nào đó cùng với công việc hàng ngày của họ và nó cũng phải được
tính cần nỗ lực và chi phí phụ thêm. Có chi phí liên kết với việc quản lí, theo dõi, thu
thập dữ liệu, và đo tất cả những hoạt động cải tiến này nữa.
Như bạn có lẽ thấy, phần lớn chi phí đều được chi tiêu để đầu tư vào người của bạn, để
huấn luyện họ, trao đổi với họ, đo việc thực hiện của họ, kiểm điểm công việc của họ,
và vượt qua sự chống cự lại thay đổi. Đó là đầu tư chính cho tổ chức nhưng tôi thực sự
tin nó đem lại phần thưởng trong tương lai.
Hỏi: “Tôi là một người quản lí phần mềm thành công nhưng sau khi dự xê mi na của
thầy về kĩ nghệ phần mềm toàn cầu, tôi sợ tất cả những thay đổi đó đang xảy ra bây giờ.
Tôi nên làm gì để tiếp tục thành công của mình?
Đáp: Là người quản lí dự án, bạn có lẽ biết rằng nguyên tắc về quản lí đã không thay
đổi trong nhiều năm nhưng công nghệ đã thay đổi vượt bực trong vài năm qua. Cái nhìn
truyền thống “Quản lí dự án mới cũng giống như chúng ta đã làm lần trước” không còn
tác dụng thêm nữa. Đó là lí do tại sao người quản lí dự án phần mềm cần liên tục nhận
diện và phân tích rủi ro. Để là người quản lí thành công, bạn có thể cần nhận biết về
công nghệ thay đổi thường xuyên, cần linh hoạt với ý tưởng mới và thực sự thích ứng
với cách thức mới về quản lí dự án phần mềm.
Hỏi: Tôi đã đọc sách CMMI nhiều lần và vẫn còn lẫn lộn về các thuật ngữ “chính sách,
thủ tục, và chuẩn”. Liệu CMMI có ngụ ý rằng “chuẩn” như thầy sẽ làm nó? “Thủ tục”

như thầy sẽ làm nó và “chính sách” như thầy phải làm nó?
Đáp: Có nhiều cách để mô tả điều này. Cái nhìn cá nhân của tôi xác định cái gì sẽ xảy ra;
nó là chỉ đạo từ quản lí cấp cao (tức là chính sách công ti). Chuẩn xác định chất lượng
của điều sẽ xảy ra, còn thủ tục xác định cách nó sẽ xảy ra. Chính sách lập ra các trông
đợi của tổ chức – rằng cách chúng ra làm mọi thứ ở đây. Chuẩn có xu hướng sản phẩm
(cả về chức năng và chất lượng) – sản phẩm công việc kết quả sẽ như cái gì, còn thủ tục
có xu hướng qui trình (thế nào) – một tập nhiều bước để làm cái gì đó.
Hỏi: Thầy nghĩ gì về quản lí cấp cao nói rằng vì hầu hết các công ti đã đạt được ISO
9001 trong vài tháng nên chúng ta cũng có thể có được CMMI mức 3 trong một năm? .
Đáp: ISO 9000 là chuẩn mức rất cao và áp dụng cho nhiều lĩnh vực (phần mềm, phần
cứng, chế tạo v.v.) nhưng CMMI là rất chi tiết và hội tụ vào kĩ nghệ phần mềm. Vì ISO
là chuẩn, nó giải quyết với câu hỏi chỉ có câu trả lời hai trị “có” và “không”, (hoặc bạn
làm hoặc bạn không làm liệu bạn có kế hoạch, thủ tục hay tài liệu không). CMMI là
khuôn khổ để cải tiến cho nên nó đề cập tới “thực hành kĩ nghệ phần mềm” như cái gì
đó được dùng tương ứng với kế hoạch và nó tốt thế nào? Nó có được đo không? Nó có
được trắc nghiệm và liên tục được cải tiến không?

3/11


CMMI-2

Dựa trên dữ liệu thu thập của tôi, thời gian trung bình để chuyển giữa các mức là từ 24
tới 36 tháng cho nên điều đó còn tuỳ thuộc vào tổ chức của bạn được đánh giá ở mức
nào để bạn có thể xác định sẽ mất bao lâu thời gian để lên mức 3.
Hỏi: Trong xê mi na “Nhập môn CMM” mà thầy dạy tại CMU, thầy có nhắc rằng tài
liệu qui trình nên vắn tắt, ngắn gọn, cỡ hai tới ba trang. Làm sao việc làm tài liệu qui
trình có thể ngắn thế được? Chúng tôi đã dành nhiều tháng làm tài liệu cho một qui trình
– vào quãng vài trăm trang, và chúng tôi vẫn chưa kết thúc. Chúng tôi có làm điều gì sai
không?

Đáp: Làm tài liệu qui trình là bước đầu tiên để cải tiến qui trình đó. Do đó, điều rất quan
trọng là tài liệu phải đơn giản và ngắn gọn bởi vì bạn sẽ cải tiến nó.
Bạn phải chống lại cám dỗ phát triển bất kì cái gì khác hơn là qui trình mức cao bởi vì
đằng nào bạn cũng sắp thay đổi nó. Lời khuyên của tôi là giới hạn xác định qui trình
vào vài nhiệm vụ then chốt và giữ nó không nhiều hơn hai tới ba trang giấy. Nếu bạn
đặt giới hạn hai trang thôi, bạn sẽ khử bỏ đi mức chi tiết không cần thiết và không thích
hợp. Cải tiến là quá trình tiến hoá mà có nghĩa là nó bắt đầu từ một thủ tục đơn giản để
đảm bảo rằng mọi người dùng nó, đồng ý với nó, tuân theo nó, đo nó, cải tiến nó và duy
trì nó. (Lập kế hoach-Thực hiện-Kiểm tra-Hành động – Plan, Do, Check, Act tới mức
chi tiết mịn hơn). Trong nỗ lực đầu tiên, dừng đi vào nhiều chi tiết bởi vì bạn không
biết qui trình bạn đang xác định thực tế có tác dụng không hay sẽ được mọi người dùng
không? Qui trình tốt nên ngắn gọn, tới từng vấn đề, dễ đọc, và nó phải rõ ràng chỉ ra
điều cần được hoàn thành. Chỉ khi mọi người dùng nó theo cách nhất quán thì bạn mới
có thể thêm mức độ chi tiết vào (Đó là điều Mức 3 và 4 trong CMMI tất cả là gì).
Làm tài liệu cho điều đơn giản trước hết và bổ sung thêm mức chi tiết khi cần thiết là
chìa khoá cho thành công trong cải tiến qui trình. Làm tài liệu cho cuốn sách khổng lồ
mà không ai dùng sẽ thực sự là phí thời gian.
Hỏi: Tôi đã thấy nhiều công cụ được quảng cáo là cải tiến các mức độ trưởng thành
CMMI. Tôi cũng gặp một số nhà tư vấn có công nghệ và khuôn mẫu có thể làm cho tổ
chức đạt tới mức 5 trong vòng một năm. Sao chúng ta không lấy các công nghệ đó bây
giờ?
Đáp: Mọi công nghệ mới bao giờ cũng tới cùng những hứa hẹn kì diệu. Đây là loại giải
pháp đã tới theo nhiều hương vị như 4GLs, AI, CASE, RAD, OOP, DCE, và công nghệ
Web. Ngược với huyền thoại phổ biến, những công nghệ này đã không đem lại cải tiến
có ý nghĩa về phẩm chất, năng suất mà cộng đồng phần mềm tìm kiếm. Cải tiến qui trình
là công việc gian nan và đòi hỏi cam kết dài hạn – không phải là cái gì đó có thể mua
được từ nhà cung cấp trong “siêu thị công nghệ”.

4/11



CMMI-2

Tôi tin rằng nhảy từ công nghệ này sang công nghệ khác, thay đổi từ công cụ này sang
công cụ kia, là thủ phạm chính giữ chúng ta không đạt tới chính ích lợi mà chúng ta hi
vọng đạt tới.
Hỏi: Tổ chức mức 1 của chúng tôi đã quyết định chấp nhận tổ chức qui trình chuẩn
phần mềm từ tổ chức được thẩm định ở mức 3 và huấn luyện cho mọi người tuân theo
qui trình đó. Việc đó có tăng tốc cải tiến của chúng tôi và thoả mãn các yêu cầu mức 3
không?
Đáp: Đây là một sai lầm thông thường mà tôi đã từng thấy nhiều công ti mắc phải: Tổ
chức CMMI mức 1 vay mượn các qui trình từ tổ chức CMMI mức 3 hay đôi khi từ tổ
chức CMMI mức 5 và hi vọng rằng họ có thể đạt tới mức đó. Liệu một học sinh phổ
thông cơ sở có thể mặc quần áo của sinh viên đại học và có thể trở thành sinh viên đại
học được không? Tôi đã thấy nhiều công ti mua các qui trình từ công ti mức cao rồi dành
nhiều thời gian viết lại các qui trình đó thành qui trình riêng của họ, buộc mọi người
phải tuân theo các qui trình đó, và tuyên bố thành công. Trưởng thành cần thời gian và
không thể bị ép buộc theo cách đó được. Cho nên với loại công ti muốn tăng tốc trưởng
thành của mình, tôi muốn hỏi:
• Làm sao bạn biết rằng các qui trình được nhận vào sẽ có tác dụng cho tổ chức
của bạn?
• Qui trình được nhận vào đó có ích và có chấp nhận được cho người trong tổ
chức của bạn không?
• Có bằng chứng về việc khi tuân theo qui trình được nhận vào đó, chất lượng,
thời gian và chi phí dự án của bạn đã được cải thiện không?
• Tổ chức của bạn có dữ liệu chỉ ra rằng chất lượng sản phẩm của bạn, mối quan
hệ với khách hàng, chỉ số thoả mãn của nhân viên, và mục đích nghiệp vụ là
được thực hiện không?
• Bạn có tin bằng việc có các qui trình chuẩn được làm tài liệu, tổ chức của bạn
tự động được cải thiện lên không?

• Bạn đang huấn luyện người dùng qui trình được nhận vào không? Hay bạn
đang huấn luyện họ để cho họ có thể trả lời được những câu hỏi nào đó trong
việc thẩm định?
Chừng nào qui trình chuẩn được nhận vào đó còn chưa thực sự được tích hợp vào cách
tổ chức thực hiện nghiệp vụ, chừng nào mọi người còn chưa hiểu nó, chưa chấp nhận
nó, chưa đón nhận việc huấn luyện để tuân theo nó, chưa dùng nó, chưa sửa đổi nó cho
khớp với nhu cầu dự án của họ, chưa đo nó, chưa cải tiến nó theo cách họ xây dựng và
bảo trì phần mềm – Chẳng cái gì sẽ thay đổi đâu.
Tôi tin sẽ là sai lầm mà ép buộc thay đổi lên các dự án bằng việc đem một qui trình bên
ngoài vào thay cho việc phát triển qui trình từ bên trong và thiết lập việc huấn luyện dựa
trên qui trình riêng của bạn.

5/11


CMMI-2

Tôi cũng tin rằng cấp quản lí của bạn đã vi phạm vào khái niệm then chốt của CMMI:
“Không nên nhảy qua các mức”. Tổ chức CMMI mức 1 nên hội tụ vào việc thiết lập
môi trường quản lí có kỉ luật trước khi thiết lập các qui trình chuẩn xuyên qua toàn tổ
chức. Một qui trình được xác định tốt từ một tổ chức CMMI mức 3 hay CMMI mức 5
chắc chắn là điều tốt, nhưng nó thường không có tác dụng tốt cho tổ chức CMMI mức
1. Làm cho tổ chức chấp nhận một qui trình chuẩn mới, có thương hiệu, dường như là
logic, nhưng không đủ trong môi trường hỗn độn của CMMI mức 1. Bạn phải có huấn
luyện và kỉ luật tại chỗ để đưa mọi sự vào kiểm soát bởi vì việc cải tiến qui trình bao
gồm việc thay đổi cách mọi người làm nghiệp vụ và thay đổi thái độ của kĩ sư; đây là lí
do tại sao điều then chốt là làm cho mọi người tham gia vào việc tạo ra qui trình chuẩn
dựa trên những thực hành tốt nhất hiện có. Thay vì mua qui trình tốt, bạn nên dành thời
gian huấn luyện cho người của mình về kĩ nghệ phần mềm, về các kỉ luật và nguyên lí
để cho mọi người hiểu vai trò của mình, trách nhiệm của mình và điều họ cần để làm

cho công việc của mình được thực hiện, đúng thời gian và có chất lượng. Xin đừng nhìn
ra ngoài về cái gì đó mới như công cụ mới, qui trình mới, phần lớn những điều tốt đều
đã có bên trong công ti bạn rồi, đó là người của bạn và tài năng của họ. Họ cần hướng
dẫn, huấn luyện để làm việc của mình. Phần lớn những người phần mềm cần giúp đỡ
trong kiểm soát yêu cầu, điều phối thay đổi, quản lí kế hoạch dự án, nhận diện những
phụ thuộc tương hỗ, và giải quyết các vấn đề thiết kế hệ thống. Đây là chỗ người quản
lí có thể thực sự giúp đỡ được bằng việc đưa ra quyền lãnh đạo.
Bởi vì công nghệ thay đổi quá nhanh, ít người phần mềm được chuẩn bị thích hợp để
dùng các ngôn ngữ và công cụ mới họ được trao cho, cho nên mới có nhiều việc học
bằng “thử và sai”, điều này thực sự là lãng phí thời gian và tiền bạc và thường bao gồm
nhiều lỗi trước khi mọi sự sẽ có tác dụng. Huấn luyện có thể là đắt nhưng không đắt
bằng KHÔNG huấn luyện. Tôi tin tưởng mạnh mẽ vào huấn luyện bởi vì việc học không
bao giờ dừng lại cho nên thay vì mua qui trình CMMI mức 5, tổ chức của bạn phải đầu
tư vào huấn luyện bởi vì đó là đầu tư tốt nhất vào cải tiến qui trình mà tôi biết tới và tôi
biết rằng điều đó bao giờ cũng có tác dụng.
—-English version—CMMI-2
Question: I have read a report stated that over 70% of organization being appraised using
CMMI failed to execute an improvement action plan and only 14% of organization
implemented their improvement over a year, far enough to conduct a re-assessment,
found no change and no improvement. Why so many process improvements failed?
Answer: I believe many organizations failed because they do not follow the
improvement phase of IDEAL model (Initiating, Diagnosing, Establishing, Acting,
and Leveraging). Most skipped the Initiating phase (The most important phase that
focus on obtaining management commitment and establish a group to improve the

6/11


CMMI-2


process) and go straight to Diagnosing phase (Conduct appraisal). Without management
commitment, things will fall apart which lead to people not executing the action plan to
solve critical issues.
I also believe that many organizations failed because they do not have the necessary
skill and experience to implement improvement activities. Many people think they know
how to make things happen since they have read books, attend seminars and be able to
talk intelligently about the subject. Process improvement is about change and change is
hard, you cannot change someone until you change yourself first. If you have not shift
your view to a higher level you cannot assist anyone to shift their view. That is why
sometime a consultant maybe helpful here. Based on my experience, following is some
reasons why process improvement failed, in priority order:
1)

No long-termed management commitment

2)

Lack of experience & skill in process improvement

3)

No clear vision of the desired results

4)

Too ambitious action plan

5)

No quantitative feedback on progress (No measurement)


6)

Wrong interpretation of CMMI

7)

Too many meetings and discussions and no action

8)

Wrong culture (Failed several times in the past, fear of change)

9)
Wrong people in SEPG (Too much time spent on document and no time to
implement)
10) Not everybody participate in the change process
Question: How much budget should be set aside for CMMI process improvement? How
do you break down and justify it?
Answer: Typical process improvement budget is about 3%-5% of the annual budget. It
may sound like a lot but it is an investment that, if successfully implemented, can bring
significant returns. Here is a breakdown of the budget:
1) The first step in getting started is the awareness of the improvement activities. People
always want to know the reason (Why), the process (How), the objectives (What) and

7/11


CMMI-2


what roadmap (When, Where) that they must follow. The best way to have all people in
the organization aware of the activities is educating them on the CMMI framework.
The “Introduction to CMMI” is a class designed for this activity. Consider the size of a
typical organization which is approx. 300 – 600 people, and each class will hold approx.
60 people. You need to schedule at least 5 to 10 classes for the organization and also set
up a special class for managers. (They need to know about the CMMI, too.) There are
costs associated with having all people take a class; but based on the data that I collected
from the past 10 years, this is a very good investment.
2) The second step is to establish a full-time group dedicated to support improvement
activities. The most common name for this group is Software Engineering Process
Group, or SEPG. The SEPG members also need additional training to do their job which
also incurs additional cost to organization.
3) The third step is to communicate all improvement activities, achievement,
measurements, goals and objectives. This should be done on a periodic basis to keep
management and people in the organization informed. Managing change requires good
communication of the changes, acknowledgment of the progress made, and
measurement of how far the organization has improved toward their goal. This activity
also requires time and effort.
There are also costs associated with having an appraisal, establishing an improvement
action plan, and the implement of improvement activities. Most people in organization
will participate in some improvement activities along with their daily work and it also
incurs additional effort and cost. There are costs associated with managing, tracking,
collecting data, and measuring all improvement activities too.
As you probably see, most of the cost is spent on investing in your own people, to train
them, communicate with them, measure their implementation, review their work, and
overcome the resistance to change. It is a major investment for the organization but I
really believe it does pay-off in the future.
Question: “I am a successful software manager but after attended your seminar on global
software engineering, I was scared of all the changes happening now. What should I do
to continue my success?

Answer: As a project manager, you probably know that the principle for management
has remained unchanged for many years but technology has changed radically in the
past few years. The traditional view “Manage new project just like we did last time”
does not work anymore. That is why software project manager need to continuously
identifying and analyzing risks. To be a successful manager you may need to be aware

8/11


CMMI-2

of the ever changing technology, be flexible for new idea and really adapting to the new
way of managing software project.
Question: I have read the CMMI book several times and still confuse about the terms
“Policy, procedure, and standard”. Does the CMMI implies that “Standard” as you shall
do it? “Procedure” as you will do it and “Policy” as you must do it?
Answer: There are many ways to describe this. My personal view is: Policy specifies
what will happen; it is a direction from senior management (i.e. Company policy). A
standard specifies the quality of what will happen, and procedure specifies how it will
happen. A policy sets the expectations of the organization – That the way we do thing
here. A standard is product-oriented (Both functional and quality) – what the resulting
work product will look like, and procedure is process oriented (How) – A set of multiple
steps for doing something.
Question: What do you think of a senior management stating that since most companies
achieved ISO 9001 in a few months we can also get CMMI level 3 in a year? .
Answer: ISO 9000 is a very high level standard and applies to many domains (Software,
Hardware, Manufacturing etc.) but CMMI is very detailed and focuses on software
engineering. Since ISO is a standard, it deals with the binary question of “yes” and
“No” answer only, (either you do or don’t whether you have a plan, a procedure or
a document). The CMMI is a framework for improvement so it addresses “software

engineering practices” as something being used according to a plan and how good is it?
Is it being measured? Is it verified and continuing to be improved?
Based on my collected data, the average time to move between levels is 24 to 36 months
so it depends on what level your organization is appraised at you can determine how
long it will take to be level 3.
Question: In the “Introduction to CMM” seminar that you taught at CMU, you
mentioned that process document should be brief, short, about two to three pages. How
could a process document be that short? We are spending months to document a single
process- about few hundred pages already, and we are not finish yet. Are we doing the
wrong thing?
Answer: To document a process is the first step to improve that process. Therefore, it is
very important that the document be simple and brief because you are going to improve
it.
You must resist the temptation to develop anything other than a high level process
because you are going to change it anyway. My advice is to limit the definition of
a process to a few key tasks and keep it to no more than two to three pages. If you
set a two-page limit, you will eliminate the level of detail that is unnecessary and not
9/11


CMMI-2

appropriated. Improvement is a evolution process which means it starts from a simple
process to ensure that everybody understand it, agree with it, use it, follow it, measure
it, improve it and then maintain it. (Plan, Do, Check, Act to a finer level of detail). In
the first attempt, do not go into much detail because you do not know the process you
are defining will actually work or will be used by everybody? A good process should be
short, to the point, easy to read, and it must clearly show what to be accomplished. Only
when people use it in a consistent way then you can add more level of detail (That’s
what Level 3 and 4 on the CMMI is all about).

To document the simple thing first and add more level of detail when necessary is the
key to success in process improvement. To document a huge book that no body will use
is really a waste of time.
Question: I have seen many tools advertised to improve CMMI maturity levels. I also
met some consultant who has technologies and templates that can make an organization
achieve level 5 within a year. Why don’t we obtain these technologies now?
Answer: Every new technology always comes with a wonderful promise. This kind of
solution has come in many flavors such as 4GLs, AI, CASE, RAD, OOP, DCE, and
Web technology. Contrary to popular myth, these technologies have not bought the
significant improvement in quality, productivity so sought by the software community.
Process improvement is hard work and requires long-term commitment – not something
one can buy from vendors in a “technology super market”.
I believe that jumping from one technology to another, changing from this tool to that
tool, is the main culprit for keeping us from achieving the very gains we hope to achieve.
Question: Our level 1 organization has decided to adopt the organization software
standard process from an organization assessed at level 3 and train all people to follow
that process. Will that accelerate our improvement and satisfy the level 3 requirements?
Answer: This is a common mistake that I have seen over and over: A level 1
organization borrows processes from a level 3 or sometime a level 5 and hope that they
can make that level. They spent a lot of time re-write these processes into their own
process, force people to follow that process, and declares success.
I would like to ask:
• How do you know that the adopted processes will work for your organization?
• Is the adopted process useful and acceptable to the people in your organization?
• Is there evidence that by following the adopted process, your project’s quality,
time, and cost has improved?

10/11



CMMI-2

• Does your organization have data to indicate that your product quality,
customer relationship, employee satisfaction index, and business goals are
realized?
• Do you believe by just having a documented standard your organization is
automatically improving?
• Are you training people to use the adopted process? Or are you training them so
they can pass certain questions during the assessment?
Unless the adopted standard process is really embedded in the organization’s culture,
unless people understand it, accept it, receive training to follow it, use it, modify it to fit
their project needs, measure it, improve it and institutionalize it as the way they build
and maintain software – Nothing will ever change.
I believe it would be a mistake for the SEPG to force changes onto projects by bringing
in an external standard process rather than to collect “best practices” from within and
establish the standard process based on these best practices.
I also believe that your SEPG has violated the key concept of CMMI: “You shall
not skip a level”. A level 1 organization should focus on establishing a disciplined
project management environment before establishing standard processes across the
organization. A well-defined process from a higher-level organization is surely a good
place to establish a standard process, but it usually does not work well for a level 1
organization. Getting an organization to adopt a new standard process by providing
training is good, but not sufficient nor effective in a chaotic environment. Improving the
process involves changing the culture and the way people do things; this is where it is
critical to get everybody participating in creating a standard process based on existing
best practices.

11/11




Tài liệu bạn tìm kiếm đã sẵn sàng tải về

Tải bản đầy đủ ngay
×