Đáp: Có vài mô hình để cải tiến qui trình phần mềm nhưng theo cách nhìn riêng của tôi, mô hình chỉ là lí thuyết mà chính kĩ năng và kinh nghiệm của người dùng nó mới làm cho mọi sự xảy ra. Trước khi quyết định dùng khuôn khổ CMMI hay cái gì đó khác, có vài nhân tố mà tổ chức nên xét tới.
1. Có những bằng chứng kinh nghiệm rằng khuôn khổ CMMI có tác dụng và phần nhiều trong đó đã được công bố trong các tạp chí phần mềm và bài báo chuyên môn. Không có bằng chứng tương tự về các mô hình cải tiến khác. Câu hỏi của tôi là tại sao tổ chức muốn dùng cái gì đó khi chúng ta không biết liệu nó có tác dụng hay không?
2. Khuôn khổ CMMI thực sự là họ các mô hình (Phần mềm, Con người, Thu nhận, Hệ thống được tích hợp v.v.) đã được chấp nhận quốc tế và được thiết kế để bổ sung lẫn cho nhau. Sự phong phú thông tin này đã giúp cho CMMI trở thành mô hình được chọn lựa cho nhiều tổ chức trên khắp thế giới.
3. Tôi đã làm việc với Watts Humphrey khi ông ấy xây dựng SW-CMM tại Viện Kĩ nghệ phần mềm – Software Engineering Institute (SEI) và đã có cái nhìn sâu sắc vào trong cách tiếp cận năm mức này: Watts nhận ra rằng có thứ tự tự nhiên đối với các vấn đề mà tổ chức phải giải quyết để cải tiến thực hành phần mềm. Ông ấy đã nhận ra rằng tổ chức phải sửa chữa lịch biểu của họ và các vấn đề dự án trước khi giải quyết các vấn đề kĩ nghệ. Bằng không, các thực hành kĩ nghệ sẽ không bao giờ có cơ hội sống còn trong sự hỗn độn được tạo ra bởi lịch biểu không thoả đáng. Vậy, nếu năng lực mức 2 mà còn chưa được thiết lập, thực hành kĩ nghệ sẽ bị hi sinh cho sức ép lịch biểu.
4. Tôi thấy rằng các mô hình khác chỉ hội tụ vào việc lấy một qui trình và cải tiến nó, bất kể tới mức độ trưởng thành hay năng lực của tổ chức. Tôi tin việc cho phép mọi người lấy ra bất kì cái gì họ muốn để cải tiến là ấu trĩ vì cấp quản lí sẽ không bao giờ cho phép các kĩ sư làm bất kì cái gì họ muốn mà không có bằng chứng cụ thể rằng nó sẽ giải quyết các vấn đề căn bản và chuyển giao sản phẩm chất lượng trong thời gian nào đó.
5. Tôi cũng tin bất kì cải tiến nào trong cô lập mà không có sự tham dự của toàn thể tổ chức sẽ dẫn tới những tình huống khó xử: Điều gì sẽ xảy ra khi bạn có qui trình kiểm thử tốt nhất nhưng làm việc trong môi trường mà phần mềm được đưa ra lại dựa trên lịch biểu cố định và thường không được kiểm thử. Cứ tưởng tượng rằng các sơ đồ kiểm soát sẽ được sinh ra bởi một qui trình ổn định trước đây lại nhận cái vào từ một qui trình mất kiểm soát. Không qui trình kĩ nghệ nào có thể đạt tới mức độ hiệu quả của nó nếu nó bị ngắt quãng bởi hỗn độn của các qui trình quanh nó.
6. Theo quan điểm quản lí, CMMI với năm mức trưởng thành là có nghĩa bởi vì ở mức 4 tổ chức có thể xác định các qui trình nào nó tin là mấu chốt nhất cho kết quả kinh doanh của nó và nhắm tới những kết quả đó với kiểm soát thống kê. Tổ chức chỉ có thể làm được điều đó sau khi nó đã thiết lập một qui trình phát triển chuẩn vững chắc (OSSP- mức 3) mà có dữ liệu và cái hiểu sâu để xác định qui trình nào là dẫn lái kinh doanh mấu chốt.
7. Theo kinh nghiệm riêng của tôi, ích lợi lớn đã được chứng tỏ ở mức 4 và 5 yêu cầu tổ chức thiết lập qui trình chuẩn đầy đủ (OSSP) có thể được tích hợp với các qui trình khác để tối ưu ích lợi – không chỉ một vài trong các qui trình mà mọi người chọn. Sự bùng nổ việc dùng lại tài sản và mức độ dự đoán được lịch biểu được quan sát thấy ở mức 4 và khả năng canh tân ở mức 5, tất cả đều yêu cầu rằng tổ chức có nền tảng qui trình vững chắc (OSSP) mà có thể được quản lí theo định lượng và rằng mọi người được huấn luyện để dùng qui trình đó. Điều này không thể được thực hiện bằng cách tiếp cận đơn giản như các mô hình khác chủ trương.
8. Nhân tiện, ngành công nghiệp phần mềm đã cố gắng cải tiến cách tiếp cận một mảnh này trong hơn 30 năm qua, mà ít hay không thành công. Từ những năm 1970, mọi người đã chọn các qui trình riêng lẻ (thiết kế, kiểm thử, viết mã v.v.) và cố gắng cải tiến chúng một cách cô lập. Việc cải tiến này đã không tồn tại bởi vì tổ chức đã không giải quyết vấn đề nền tảng của mình – kiểm soát lịch biểu dự án. Watts Humphrey đã nhận ra nhu cầu cần tối ưu vấn đề ông ấy phải giải quyết. Khuôn khổ trưởng thành là con đường logic để cải tiến toàn thể qui trình phát triển.
9. Các mô hình CMMI tạo ra văn hoá khác nhau tại từng mức trưởng thành. Chẳng hạn, các tổ chức mức 3 có thể được quan sát thấy cách văn hoá chuyên nghiệp có ảnh hưởng bằng việc chia sẻ những thực hành tốt nhất. Văn hoá bao gồm nhiều thực hành chung và nhiều người chia sẻ, điều tốt hơn là văn hoá sẽ nổi lên. Cách tiếp cận khác không làm cho tổ chức bị tràn ngập bởi những thực hành chung, và điều như vậy quả ít làm thay đổi văn hoá của tổ chức. Thay đổi văn hoá là rất mấu chốt để thể lệ hoá các thực hành và đạt tới ích lợi của cải tiến qui trình.
Tôi chắc chắn trong tương lai có thể có những mô hình tốt hơn nhưng vào lúc này, tôi biết CMMI có tác dụng tốt trong nhiều tổ chức và đó là lí do tại sao tôi chủ trương mô hình này hơn các mô hình khác.
Hỏi: Công ti của tôi được một nhà tư vấn đánh giá năm ngoài là ở CMMI mức 1. Ông chủ của tôi không thích kết quả này cho nên ông ấy thuê một nhà tư vấn khác. Nhà tư vấn mới tới đem theo nhiều khuôn mẫu và tài liệu cho công ti chúng tôi dùng, kể cả dữ liệu mẫu và trong vòng mười tháng, ông ấy đã đánh giá công ti tôi là CMMI mức 5. Thầy nghĩ chúng tôi đáng phải ở mức nào?
Đáp: Không tiến hành đánh giá, tôi không thể nói được về mức độ trưởng thành của công ti bạn. Tuy nhiên, có thể là nhà tư vấn đầu là người trung thực và đã đánh giá công ti bạn ở mức 1 vì nó không có qui trình nào được làm tài liệu. Nhà tư vấn thứ hai đã đem tới tài liệu và khuôn mẫu riêng của ông ấy rồi dùng chúng làm bằng chứng rằng công ti bạn đã có tất cả các qui trình được làm tài liệu cũng như dữ liệu thống kể cho nên ông ấy có thể đánh giá công ti bạn ở mức cao hơn (mức 5). Điều này có thể được coi là “lừa bịp” và có thể là ông ta đã bán mức độ trưởng thành với giá mà công ti bạn sẵn lòng trả.
Vấn đề của tôi không phải là với nhà tư vấn mà là với ông chủ của bạn. Tại sao ông ấy muốn đạt tới cái gì đó mà công không có và lí do để làm điều đó là gì? Ông ấy có muốn quảng cáo cho công ti mình ở mức trưởng thành cao với hi vọng rằng mọi người sẽ mua sản phẩm và dịch vụ của bạn sao? Trong trường hợp đó, ông ấy có thể tiết kiệm nhiều tiền bằng việc in một mảnh giấy nói rằng công ti đang ở CMMI mức 5 thay vì trả tiền cho nhà tư vấn.
Tôi cũng nghĩ bất kì ai tin vào “Quảng cáo CMMI mức” như đảm bảo cho chất lượng cao mà không kiểm chứng điều đó, thì không phải là thông minh mấy. Về căn bản, loại lừa bịp này là rất ấu trĩ bởi vì phần lớn mọi người không biết họ đang mua gì và sẽ không bao giờ làm ăn với công ti có ý định lừa bịp họ bằng quảng cáo giả. Khi mọi người thấy các công ti nói đạt tới mức độ trưởng thành cao và nhìn vào chất lượng của công việc được chuyển giao, họ có thể nói điều khác và tất nhiên, họ không bao giờ làm ăn với công ti đó nữa.
Hỏi: Khi lập kế hoạch cải tiến qui trình phần mềm bằng việc dùng CMMI làm khuôn khổ, vấn đề chuyển sang mức 3 là gì khi so với đạt tới mức 2 như điều tiên quyết? Tôi không thấy khác biệt gì nếu SEPG yêu cầu người làm phần mềm cho phép qui trình chuẩn được xác định.
Đáp: Ý tưởng về SEPG “áp đặt” các qui trình mức 3 lên một nhóm mức 1 gồm những người chưa được huấn luyện để tuân theo mức 2 là rất khó. Cứ hình dung ai đó tới và bảo mọi người phát triển rằng cách thức họ đã làm việc cho tới giờ là tồi, và đây là cách làm mới, mà SEPG đã xác định cho họ tuân theo và đây là cách chúng ta làm việc từ giờ trở đi. Bạn nghĩ gì nếu bạn là người phát triển làm việc chăm chỉ cần mẫn? Bạn có cho rằng bạn sẽ nghe ai đó mà bạn không biết bảo bạn cách bạn làm việc của mình không? Bất kì ai cũng có thể viết ra các qui trình, chính sách, thủ tục v.v. mức 3 nhưng lại cần nhiều tri thức và kĩ năng để hiểu cách thay đổi tổ chức bên trong những hành vi tập thể duy nhất của nó.
Về căn bản, ở mức 1, không ai biết cái gì làm việc, cái gì không làm việc vì chẳng cái gì được làm tài liệu. Phải mất thời gian viết ra điều những người phát triển làm như một công cụ trao đổi để thực sự hiểu cái gì thực sự làm việc, cái gì không làm việc và làm sao cải tiến chúng. Đây là bước đầu tiên của mọi cải tiến; bạn phải biết bạn ở đâu trước khi bạn có thể đi đâu đó.
Ở mức 2, có một số điều có thể được làm mà không yêu cầu rằng chúng được thực hiện theo cách thức chuẩn. Mọi dự án đều được yêu cầu làm tài liệu về các qui trình riêng của họ thay vì tuân theo cái gì đó được người khác làm tài liệu. Hệ quả là, tổ chức có thể có một số qui trình đa dạng được thiết lập trong các dự án khác nhau. Tuy nhiên, đây là chỗ nền tảng được đặt ra bởi vì các qui trình này được những người phát triển tạo ra. Dựa trên dữ liệu đo được SEPG thu thập, họ có thể xác định về tính hiệu quả và hiệu lực của các qui trình đa dạng để nhận diện cái gì có tác dụng tốt nhất. Nhóm SQA sẽ đảm bảo rằng độ đo được xác định rõ và tương ứng với thực tại. Phân tích này về các qui trình mức 2 sẽ cho phép SEPG hợp nhất và cải tiến các qui trình này thành thực hành tốt nhất chuẩn, đưa tới qui trình tổ chức mức 3.
Các mức trưởng thành của CMMI được tạo ra dựa trên nhiều năm nghiên cứu tại Đại học Carnegie Mellon và chúng phục vụ mục đích cho phép tổ chức trưởng thành qua thời gian. Xin đừng nhảy qua các mức.
Hỏi: Ở mức 3, chúng tôi đã thiết lập qui trình chuẩn của tổ chức và cung cấp huấn luyện cho mọi người làm phần mềm trong tổ chức chúng tôi. Chúng tôi không biết phải làm gì để đạt tới mức 4?
Đáp: Ở CMMI mức 4, việc hội tụ của cải tiến hội tụ được mở rộng sang cả dự án và nghiệp vụ của tổ chức.
Ở mức tổ chức, bạn cần:
1) Thiết lập tuyến cơ sở hiệu năng, đặc trưng cho hiệu năng qui trình mong đợi của các qui trình chuẩn của tổ chức.
2) Thiết lập các mục tiêu chất lượng cho mọi dự án phần mềm. Chẳng hạn không quá X lỗi trên KLOC; không quá Y % biến thiên giữa kế hoạch được ước lượng so với thực tại.
3) Để tổ chức lựa ra các qui trình hay qui trình con trong các qui trình chuẩn của tổ chức để phân tích hiệu năng như thiết lập các giới hạn kiểm soát (cận trên & cận dưới)
4) Để tổ chức thiết lập Cách đo Hiệu năng-Qui trình bằng việc duy trì các định nghĩa về cách đo mà được đưa vào trong các phân tích hiệu năng-qui trình của tổ chức.
6) Để tổ chức lựa chọn cách đo và kĩ thuật phân tích được dùng trong quản lí theo thống kê qui trình được lựa cho mọi dự án.
Ở mức dự án, bạn cần:
1) Thiết lập các mục tiêu hiệu năng của dự án như lập các mục đích chất lượng, mục đích tuân thủ qui trình định lượng (chẳng hạn: Số các qui trình dưới kiểm soát thống kê)
2) Lựa các qui trình con bên trong qui trình được xác định của dự án để được quản lí thống kê dựa trên sự ổn định lịch sử và dữ liệu năng lực. Bạn cần nhận diện các giới hạn kiểm soát bằng việc phân tích dữ liệu riêng của mình.
3) Phân tích hiệu năng tập thể của các qui trình con của dự án để dự đoán liệu các mục tiêu của dự án về chất lượng và hiệu năng qui trình sẽ được thoả mãn và nhận diện nhu cầu hành động sửa chữa thích hợp.
4) Dùng các mô hình hiệu năng qui trình đã định cỡ để nhận diện, phân tích và thực hiện hành động sửa đổi khi cần.
5) Nhận diện và quản lí thống kê về các qui trình con được lựa bên tronng qui trình được xác định của dự án bằng việc lập giới hạn kiểm soát.
6) Để SQA kiểm điểm liệu có chắc chắn dự án tuân theo cách đo và các kĩ thuật phân tích được tổ chức lựa cho việc quản lí các qui trình của nó không?
7) Thiết lập và hiểu biến thiên của các qui trình con được lựa bằng việc dùng các cách đo và kĩ thuật phân tích được lựa.
8) Nhận diện, đề cập, và ngăn cản việc tái xuất hiện của các nguyên nhân biến thiên đặc biệt trong các qui trình con được lựa.
9) Phân tích hiệu năng của các qui trình con được lựa để dự đoán năng lực của chúng để thoả mãn chất lượng và các mục tiêu hiệu năng-qui trình của chúng, và lấy hành động sửa chữa khi cần.
10) Ghi lại dữ liệu thống kê và quản lí chất lượng trong kho cách đo của tổ chức dành cho phân tích tương lai.
11) Lựa dữ liệu nào đó cho phân tích bằng việc dùng tiêu chí đã thiết lập.
12) Phân tích nguyên nhân chung của biến thiên để hiểu phẩm chất cố hữu và các ràng buộc hiệu năng qui trình.
Điều sau đây được nói tới ở CMMI mức 5, nhưng tôi nghĩ ở mức 4 bạn có thể thực hiện nó song song thay vì tuần tự:
13) Tiến hành phân tích nhân quả với các vấn đề được lựa để xác định căn nguyên của chúng (Điều này có nhiều hơn ở mức 5 nhưng bạn có thể làm điều đó thậm chí ở mức 4)
14) Đề nghị các hành động để đề cập tới các nguyên nhân chung được lựa của biến thiên và ngăn ngừa việc tái xuất hiện của các vấn đề được lựa trong tổ chức.
15) Đệ trình các đề án cải tiến qui trình và công nghệ dựa trên dữ liệu lịch sử và phân tích hiệu năng dự án?
Hỏi: Liệu có thể để người phát triển trong dự án thực hiện cả các chức năng SQA và kiểm điểm ngang quyền không? Tại sao có và tại sao không?
Đáp: Thuật ngữ Kiểm điểm ngang quyền, như tên của nó ngụ ý, được thực hiện bởi “người ngang quyền” hay những người đang làm việc trong dự án cùng bạn để kiểm điểm KHÔNG CHÍNH THỨC công việc của bạn để xác định xem liệu nó có tốt không nhưng sẽ không đánh giá hay trắc nghiệm sản phẩm của bạn để được chấp nhận chính thức. Việc kiểm điểm như vậy được thực hiện với mục đích phát hiện, sớm nhất có thể được, bất kì vấn đề nào trong vật phẩm phần mềm của bạn (kế hoạch, thiết kế, mã, v.v.).
SQA được thực hiện bởi những người đang ở vị trí trắc nghiệm KHÁCH QUAN sản phẩm và qui trình phần mềm. Bạn phải đừng quên rằng ý định của SQA là yêu cầu cách nhìn KHÁCH QUAN và phải KHÔNG thiên vị cho nên SQA KHÔNG nên được thực hiện bởi những người đang làm việc trong dự án.
Hỏi: Công ti tôi được đánh giá ở CMMI mức 5. Chúng tôi phải làm gì tiếp? Có mức 6 không? Tôi nghĩ mức 4 và 5 là dễ đạt tới hơn mức 2 hay 3. Thầy nghĩ sao?
Đáp: Nếu bạn thành công, đà sẽ có đó và tôi không ngạc nhiên với nhiệt tình của bạn để tiếp tục sang mức sau. Theo kinh nghiệm của tôi, tổ chức đã thành công trong cải tiến qui trình và làm chủ tất cả các miền qui trình của mức 2 và 3 có thể đi nhanh hơn vào hai mức tiếp. Một số tổ chức thậm chí còn có thể làm việc trên miền qui trình của mức 4 và mức 5 song song thay vì tuần tự. Tôi nghĩ Phân tích nhân quả và giải pháp có thể được thực hiện ở mức 4 vì mức 4 họi tụ vào việc dùng dữ liệu để cải tiến nghiệp vụ tổ chức. Nhận diện nguyên nhân của vấn đề và khử bỏ chúng là điều đúng cần làm và không cần đợi tới mức 5.
Tôi tin hội tụ của mức 5 là vào việc duy trì tuyệt hảo bằng việc biểu lộ tuyệt hảo hiệu năng và đo được. Ở mức 5, tổ chức đã trưởng thành đầy đủ bằng việc có hiệu năng nhất quán trong mọi khía cạnh. Vấn đề ở đây là làm sao duy trì đà của tuyệt hảo phần mềm trong môi trường thay đổi nhanh chóng.
Hỏi: Làm sao thầy đo kích cỡ phần mềm nếu thầy không dùng dòng mã (LOC) hay điểm chức năng (FP)?
Đáp: Đo kích cỡ có thể thay đổi trong vòng đời phần mềm. Chẳng hạn, đo kích cỡ của pha yêu cầu là số các yêu cầu. Đo kích cỡ của pha thiết kế là số các phần tử thiết kế. Đo kích cỡ của pha thực hiện là số dòng mã, chương trình con, đối tượng hay lớp đối tượng trong mã nguồn đã hoàn thành.
Hỏi: Là sinh viên, em thực sự thích lớp kĩ nghệ phần mềm tại Carnegie Mellon nhưng em bây giờ đang làm việc và không có thời gian học thêm.
Đáp: Tất cả chúng ta đều bận rộn với cuộc sống thường ngày của mình để giữ cân bằng giữa công việc và gia đình. Không mấy người có thể đảm đương được việc để thời gian cho đào tạo vốn là điều bản chất để vẫn còn hiện hành cùng công nghệ. Chúng ta biết rằng để vẫn còn có là cá nhân có khả năng cạnh tranh trong thời đại thay đổi, việc học liên tục là cấu phần mấu chốt cho thành công. Điều quan trọng cần biết xu hướng trong công nghiệp, biết cái gì là quan trọng và cái gì không, và liên tục học và trưởng thành cả như một con người và nhà chuyên môn. Tuy nhiên, học tập không nhất thiết có nghĩa bạn phải tham dự lớp học. Bạn có thể học nhiều từ các hoạt động thường ngày của mình, từ dự án của bạn, từ người khác và từ bạn của bạn. Cơ hội học tập là vô tận nếu bạn nghiêm chỉnh về học tập. Tôi mạnh mẽ tin tưởng vào học cả đời từ mọi cơ hội.
Trước khi về nhà mỗi ngày, tôi bao giờ cũng dành vài khoảnh khắc để suy nghĩ về hoạt động trong ngày với ý định thu được cái nhìn sâu và học từ sai lầm của mình. Tôi bao giờ cũng nói với tổ của tôi và hỏi họ về xu hướng trong công nghiệp và cái gì là điều tôi phải biết. Tôi bao giờ cũng viết thư trao đổi với bạn bè, nhiều người là các giáo sư ở đại học, để biết họ đang làm loại nghiên cứu gì để cho tôi có thể học được từ họ. Tôi nghĩ tất cả chúng ta đều có thể làm cùng điều đó. Đừng để thời gian trôi qua mà không học. Tâm trí là thứ dễ phí hoài kinh khủng.
Hỏi: Tại sao chúng ta khoán ngoài phát triển phần mềm cho các công ti khác? Rủi ro của việc không xây dựng phần mềm trong nội bộ là gì?
Đáp: Xu hướng hiện thời ngày nay là khoán ngoài một phần việc phát triển phần mềm cho các công ti khác. Có nhiều lí do để làm điều đó như tổ chức có thể không có đủ tài nguyên để việc đó được thực hiện trong nội bộ, hay họ không có các kĩ năng mấu chốt để làm nó. Tuy nhiên, khoán ngoài là kĩ năng rất đặc thù trong bản thân nó cần sự chú ý đặc biệt. Nếu công ti gặp thời kì khó khăn trong quản lí các dự án riêng của mình, đâu sẽ là cơ hội cho quản lí thành công dự án đi nửa đường quanh thế giới? Nếu yêu cầu tiếp tục thay đổi, làm sao bạn kiểm soát và quản lí được những thay đổi đó?
Khoán ngoài đòi hỏi nhu cầu về các yêu cầu được viết tốt – rõ ràng, chính xác, và kiểm tửh được. Điều rất quan trọng là đặt nỗ lực lớn vào hoạt động này để đi tới hợp đồng xác định rõ ràng phạm vi, vật chuyển giao, lịch biểu và cơ chế kiểm soát thay đổi. Điểm then chốt khác khi làm việc với các công ti khác là ở chỗ bạn phải có ít nhất nhiều kiểm soát và hiểu thấu vào điều đang diễn ra như bạn làm việc với nhóm riêng của mình. Quản lí và điều phối nhà cung cấp của bạn là vấn đề rất quan trọng. Đó là lí do tại sao CMMI yêu cầu kĩ năng này ở mức 2 (Quản lí nhà thầu). Khi làm việc với nhà cung cấp, tổ chức phải có quyền đảm bảo rằng họ có cái nhìn sâu vào trong qui trình được dùng và tiến độ so với vật chuyển giao. Nếu nhà cung cấp không muốn cung cấp việc nhìn sâu đó để giảm nhẹ rủi ro của bạn, bạn có thể khôn ngoan nhìn sang nơi nào đó khác.
Khi vấn đề nảy sinh trong tình huống khoán ngoài, giải pháp thường được tìm trong chi tiết của hợp đồng. Điều không được viết ra có thể bị áp đặt. Do đó, bạn phải soạn thảo cẩn thận hợp đồng để tránh lâm vào điểm có vấn đề đó.
Hỏi: Có nhiều mô hình kinh doanh điện tử: doanh nghiệp với khách hàng Business to Consumer (B2C), doanh nghiệp với doang nghiệp Business to Business (B2B). Thế còn doanh nghiệp với chính phủ Business to Government (B2G) thì sao? Liệu có thị trường để làm kinh doanh điện tử với chính phủ không?
Đáp: Mặc dầu nhiều chính phủ đã bị tụt lại sau khu vực tư nhân trong việc vào trực tuyến, tôi tin thương mại điện tử doanh nghiêp với chính phủ, được biết là B2G hay G2B, là rất lớn. Nhiều công ti tư gần đây đã bắt đầu tổ chức các website chính phủ và xây dựng thị trường ảo của chính phủ. IBM gần đây đã cộng tác với chính phủ Mĩ để cung cấp tư vấn trực tuyến cho các cơ quan chính phủ và tạo ra website chính phủ để phục vụ nhu cầu công dân. Có việc tăng mạnh sự thừa nhận của chính phủ về giá trị của việc đưa mọi thứ lên web và giá trị chúng có thể đem lại cho các công dân. Nhóm Gartner ước lượng chi tiêu về thương mại điện tử của chính phủ liên bang, chính phủ bang và chính quyền địa phương sẽ tăng từ $1 tỉ đô la năm 2000 lên hơn $16 tỉ trong năm 2010. Có thể là thị trường B2G có thể trở thành thị trường thương mại điện tử lớn nhất thế giới, có thể làm giảm nhu cầu của chính phủ với nhân viên hành chính và cũng sinh ra thu nhập cho công ti xây dựng và giữ website của chính phủ.
Hỏi: Mĩ có còn là số một trong phần mềm hay Ấn Độ đã vượt qua chúng ta? Xin cập nhật cho chúng tôi về những xu hướng này.
Đáp: Vào lúc này, Mĩ vẫn dẫn đầu nhưng Ấn Độ không xa đằng sau. Nếu xu hướng này tiếp tục, trong vài năm tới, Mĩ và Ấn Độ có thể rất gần nhau.
Đây là một số dữ liệu: xuất khẩu phần mềm của Ấn Độ năm 2007 tổng $60 tỉ đô la Mĩ với 70% xuất khẩu sang Mĩ. Ngày nay các công ti của Ấn Độ như TCS, H.C.L, Wipro, và Infosys Technologies đều nổi tiếng ở Mĩ và trên thế giới. Xuất khẩu phần mềm Ấn Độ chiếm 24% kinh doanh này trên toàn thế giới. Người ta ước lượng rằng xuất khẩu của Ấn Độ năm 2010 sẽ tăng xấp xỉ $100 tỉ đô la, sẽ chiếm 30% thị phần kinh doanh phần mềm toàn thế giới. Nhân tiện, lương kĩ sư phần mềm Ấn Độ cũng đã tăng đáng kể trong vài năm qua do nhu cầu cao. Nhiều người không muốn làm chỉ lập trình mà đòi hỏi vai trò lớn hơn trong quản lí dự án, thiết kế hệ thống, và tích hợp qui mô lớn và họ đã khoán ngoài phát triển phần mềm cho các nước có chi phí thấp khác.
Hỏi: Tại sao chúng tôi cần làm tài liệu qui trình? Nó là hoạt động gia tăng giá trị hay chỉ để thoả mãn các yêu cầu CMMI?
Đáp: Kĩ nghệ phần mềm là kinh doanh nặng về tri thức. Tuy nhiên, tri thức này không được làm tài liệu cho người khác dùng nhưng được giữ trong đầu của người phát triển. Khi họ ra đi, họ đem tri thức của mình đi cùng họ và tri thức không được làm tài liệu bị mất. Tri thức là tài sản, giá trị, và sở hữu trí tuệ của công ti. Không có tài liệu, công ti thậm chí không biết loại tri thức nào mình bị mất.
Ta hãy hình dung rằng chúng ta có thể dùng lại mọi kinh nghiệm và tri thức về cách phát triển thành công phần mềm hay quản lí dự án. Điều đó sẽ mạnh mẽ và đáng muốn biết bao! Nắm bắt tri thức là điều việc làm tài liệu qui trình tất cả là gì – cách biểu diễn và cất giữ tri thức và công cụ nào dùng để thu nhận, cất giữ, tìm kiếm và truy lục tri thức và kinh nghiệm một cách hiệu quả và hiệu lực.
Nhân tiện, câu hỏi và câu trả lời này trên website này là cách khác để làm tài liệu và chia sẻ tri thức của tôi với tất cả các bạn.
Hỏi: Sao chúng ta cần kiểm điểm đều kì về hoạt động cải tiến? Nó có phải là quản lí vi mô không?
Đáp: Không, nó không phải là quản lí vi mô mà là cách hiệu quả để điều phối đầu tư của tổ chức vào cải tiến qui trình. Kiểm điểm đều kì về hoạt động cải tiến tạo khả năng cho người quản lí truy nhập vào tiến bộ cải tiến, vấn đề hiệu năng mấu chốt, phân tích kết quả cải tiến để vi chỉnh và tối ưu doanh nghiệp, thu lấy tính thấy được trong nhiệm vụ cải tiến và tác động của chúng lên hiệu năng của tổ chức.
Question: Why do you advocate software process improvement using the CMMI framework? Why not other models?
Answer: There are several models to improve the software process but from my own perspective, a model is just a theory but it is the skills and experiences of people who use it to make things happen. Before decide to use the CMMI framework or something else, there are few factors that the organization should consider.
1. There are empirical evidences that the CMMI framework does work and much of it published either in software journals and professional papers. There is no similar evidence on other improvement models. My question is why would an organization want to use something when we don’t know whether it will work or not?
2. CMMI framework is really a family of models (Software, People, Acquisition, System integrated etc.) that have been adopted internationally and designed to complement one another. This richness of information has helped the CMMI to become the model of choice for many organizations all over the world.
3. I worked with Watts Humphrey when he developed the SW-CMM at the Software Engineering Institute (SEI) and do have some insight into the five- level approach: Watts realized that there was a natural ordering to the problems an organization must solve to improve software practices. He realized that an organization must fix their schedule and project problems before solving engineering problems. Otherwise, the engineering practices would never have a chance to survive in the chaotic created by unreasonable schedules. Thus, if a Level 2 capability were not established, engineering practices would be sacrificed to schedule pressures.
4. I found that other models only focusing on taking any single process and improving it, regardless of maturity level or capability of an organization. I believe allowing people to pick whatever they want to improve is naïve since management will never allow engineers to do whatever they like without concrete evidence that it will solve basic problems and deliver quality product within a certain time.
5. I also believe any improvement in isolation without the entire organization involvement will lead to awkward situations: What would happen when you have the best testing process but work in an environment where software is released based on a fix schedule and frequently not tested. Imagine that the control charts that will be generated by a formerly stable process receive input from an out of control process. No engineering process can achieve its level of efficiency if it is disrupted by the chaos of the processes around it.
6. From the management point of view, CMMI with five maturity levels makes sense because at level 4 the organization can determine which processes it believes are most critical to its business results and target those for statistical control. The organization can only do that after it has established a solid standard development process (OSSP- Level 3) that has the data and insight to determine which processes are the critical business drivers.
7. Based on my own experiences, the strong benefits that have been demonstrated at Levels 4 and 5 require the organization established a full standard process (OSSP) that can be integrated with others’ processes to optimize the benefits—not just a few of the processes that people choose. The explosion of asset reuse and the level of schedule predictability observed at level 4 and the ability to innovate at level 5, all require that the organization has a solid standard process foundation (OSSP) that can be quantitatively managed and that people are trained to use that process. This cannot be accomplished by a single approach as other models advocates.
8. By the way, the software industry has been trying to improve in this single piece approach for more than 30 years, with little or no success. Since the 1970s, people has selected individual processes (design, testing, coding etc.) and tried to improve them in isolation. The improvements did not survive because the organization did not solve its fundamental problem—controlling the project schedule. Watts Humphrey realized the need to prioritize the problems he had to solve. The maturity framework was a logical path to improving the whole development process.
9. The CMMI models create different cultures at each maturity level. For example, Level 3 organizations can be observed to see how a professional culture took hold by the sharing of best practices. A culture is composed of many shared practices and the more people share, the better that culture will emerge. Other approach does not cause the organization to be pervaded by common practices, and as such does little to change the organization’s culture. Cultural change is very critical to institutionalizing the practices and achieving the benefits of process improvement.
I am sure in the future there could be better models but at this time, I know the CMMI works well in many organizations and that is why I advocate this model over others.
Question: My company is appraised last year at CMMI Level 1 by a consultant. My boss did not like the result so he hired another consultant. The new consultant came with many templates and documents for our company to use, including sample data and within ten months, he appraised my company as CMMI Level 5. What level do you think we should be at?
Answer: Without conduct an appraisal, I can not tell about the maturity level of your company. However, it is possible that the first consultant was honest and appraised your company as Level 1 since it does not have any documented processes. The second consultant brought in his own documents and templates then use them as evidences that your company already had all the documented processes as well as statistical data so he could appraise your company at higher level (Level 5). This could be considered “Cheating” and it is possible that he sold the maturity level at a price your company was willing to pay.
My issue is not with the consultant but with your boss. Why would he want to achieve something that the company is not and what is the reason for doing that? Does he want to advertise the company as a high maturity level with the hope that people will buy your products and services? In that case, he could save a lot of money by print out a piece of paper claiming that the company is a CMMI level 5 rather than pay the consultant.
I also think anyone who believes an “Advertising CMMI level” as a guarantee of high quality without verifying it, is not very smart. Basically, this kind of cheating is very naïve because most people do know what they are buying and would never do business with company that is intentionally cheating them by false advertising. When people saw companies claim to achieve a high maturity level and look at the quality of the work being delivered, they can tell the different and of course, they never do business with that company again.
Question: When planning software process improvement using the CMMI as the framework, what are the problems of going for Level 3 as opposed to achieve Level 2 as a prerequisite? I do not see the different if SEPG requires software people to follow a defined standard process.
Answer: The idea of SEPG “imposing” level 3 processes on a group of level 1 people who are not yet trained to follow a level 2 is very difficult. Imagine somebody come and tell all developers that the way they have been working so far is bad, and this is the new way, that the SEPG defined for them to follow and this is how we are working from now on. What do you think if you are a hard working developer? Do you think that you will listen to someone that you do not know tell you how to do your job? Anyone can write Level 3 processes, policies, procedures, etc. but it takes a lot of knowledge and skills to understand how to change an organization within its unique collective behaviors.
Typically, at Level 1, nobody knows what works, what does not work since nothing is documented. It takes time to write down what developers do as a communication tool to really understand what really works, what does not work and how to improve them. This is the first step of all improvements; you must know where you are before you can go somewhere.
At level 2, there are number of things can be done without requiring that they be performed in a standard manner. All projects are requested to document their own processes rather than following something documented by another. As a consequence, the organization may have some diverse processes established in different projects. However, this is where the foundation is laid because these processes are created by the developers. Based on measurements data collected by the SEPG, they can determine on the efficiency and effectiveness of the various processes to identify what is working best. The SQA group will ensure that the metrics are well defined and correspond to the reality. This analysis of the existing Level 2 processes will allow the SEPG to consolidate and improve these processes into the standard best practices, leading to a level 3 organizational process.
The maturity levels of the CMMI are created based on many years of research at CarnegieMellonUniversity and they serve a purpose of allowing the organization to mature over time. Please do not skip level.
Question: As a Level 3, we have established organization standard process and provide training to all software people in our organization. We do not know what to do to achieve Level 4?
Answer: At CMMI Level 4, the improvement focus is broaden to both project and organization business.
At the organization level, you need to:
1) Establish a performance baseline, which characterize the expected process performance of the organization’s standard processes.
2) Set quality objectives for all software projects. For example no more than X defects per KLOC; no more than Y % variation between estimated plan vs. actual.
3) Have the organization select processes or sub-process in the organization’s standard processes for performance analyses such as set control limit (upper & lower bound)
4) Have the organization establish Process-Performance Measures by maintain definitions of the measures that are to be included in the organization’s process-performance analyses.
6) Have the organization selected the measures and analytical techniques to be used in statistically managing the selected process for all projects.
At the project level, you need to:
1) Establish the project’s performance objectives such as set quality goals, quantitative process compliance goal (for example: Number of process under statistical control)
2) Select the sub-processes within the project’s defined process to be under statistical managed based on historical stability and capability data. You need to identify control limits by analyze your own data.
3) Analyze the collective performance of the project’s sub-processes to predict whether the project’s objectives for quality and process performance will be satisfied and identify the need for corrective action as appropriate.
4) Use calibrated process performance models to identify, analyze, and execute corrective action when necessary.
5) Identify and statistical manage performance of selected sub-processes within the project’s defined process by setting control limit.
6) Have SQA review to make sure project follow the measures and analytical techniques selected by the organization for managing its processes?
7) Establish an understanding of the variation of the selected sub-processes using the selected measures and analytical techniques.
8) Identify, address, and prevent reoccurrence of special causes of variation in the selected sub-processes.
9) Analyze the performance of the selected sub processes to predict their capability to satisfy their quality and process-performance objectives, and take corrective action as necessary.
10) Record statistical and quality management data in the organization’s measurement repository for future analysis.
11) Select certain data for analysis, using established criteria.
12) Analyze common causes of variation to understand the inherent quality and process performance constraints.
The following are addressed at CMMI level 5, but I think at Level 4 you can do it concurrently rather than serially:
13) Conduct causal analysis on selected problems to determine their root causes (This is more a Level 5 but you can do it even at level 4)
14) Propose actions to address selected common causes of variation and to prevent recurrence of selected problems in the organization.
15) Submit process- and technology-improvement proposals based on historical data and project performance analysis?
Question: Is it possible to have developers in project performing both SQA and Peer Review functions? Why and why not?
Answer: The term Peer Reviews, as its name implies, are done by “Peers” or people who are working on the project with you to INFORMALLY review your work to determine if it is good but will not evaluate you or verify your products for formal acceptance. Such reviews are done for the purpose of detecting, as early as possible, any problems in your software artifacts (plan, design, code, etc.).
SQA is done by people who are in a position to verify OBJECTIVELY the software products and processes. You we must not forget that the intent of SQA is requiring an OBJECTIVE view and should NOT be biased so SQA should NOT be performed by people who work on the project.
Question: My company is appraised at CMMI Level 5. What should we do next? Is there a Level 6? I think level 4 and 5 are easy to achieve than level 2 or 3. What do you think?
Answer:
If you are successful, the momentum would be there and I am not surprised at your enthusiast to continue to the next level. Based on my experiences, organizations that have been successful in process improvement and master all the process areas of level 2 and 3 can move faster in the next two levels. Some could even work on process areas of Level 4 and Level 5 concurrently rather than serially. I think the Causal Analysis and Resolution can be done at Level 4 since Level 4 is focusing on using data to improve the organization business. Identify the cause of problems and eliminate them is the right thing to do and do not need to wait until Level 5.
I believe the focus of Level 5 is on sustaining excellence by a demonstration of measurable and performance excellence. At level 5, the organization is fully matured by having consistent performance in every aspect. The issue here is how to sustain the momentum of software excellence in a rapidly changing environment.
Question: How do you measure software size if you do not use Line of code (LOC) or Function Point (FP)?
Answer: The size measure can vary in the software life cycle. For example, the size measure of the requirements phase is the number of requirements. The size measure of design phase is the number of design elements. The size measure of implement phase is the number of lines of code, subroutines, object or class of object in the completed source code.
Question: As a student, I really enjoy your software engineering classes at Carnegie Mellon but I am working now and do not have time to learn more.
Answer: All of us are busy with our daily life of balancing between work and family. Not many can afford to take time out for the training that is essential to stay current with technology. We know that to stay competitive in the changing time as an individual, ongoing learning is a critical component to success. It is important to know the trends in the industry, to know what is important and what is not, and to continue to learn and grow both as a person and a professional. However, learning does not necessarily mean you have to attend classes. You can learn a lot from your daily activities, from your projects, from others and from your friends. The opportunity to learn is endless if you are serious about learning. I am strongly believed in lifelong learning from every opportunity. Before going home each day, I always spend a few moments to reflect on the day’s activities with the intent to gain insight and learn from my mistakes. I always talk to my team and ask them about the trends in the industry and what are things that I should know. I always correspondent with my friends, many are professors in universities, to know what kind of research that they are doing so I can learn from them. I think all of us can do the same. Do not let time go by without learning. A mind is a terrible thing to waste.
Question: Why are we outsourcing software development to other companies? What are the risks of not building software internally?
Answer: The current trend today is to outsource part of the software development to other companies. There are many reasons for doing it such as the organization may not have enough resources to get the job done internally, or they do not have the critical skills to do it. However, outsourcing is a very special skill in itself that needs special attention. If the company has a difficult time managing their own projects what would be the chance of successfully managing a project half way around the world? If the requirements continue to change, how would you control and manage those changes?
Outsourcing requires the need for well-written requirements—clear, concise, and testable. It is very important to put significant effort into this activity to come up with a contract that clearly specifies scope, deliverables, schedule, and change control mechanism. Another key point when working with other companies is that you should have at least as much control and insight into what is going on as you would with your own group. Managing and monitoring your suppliers are very important issues. That is why CMMI requires this skill at Level 2 (Subcontract Management). When working with suppliers, the organization must have the right to ensure that they have insight into the process being used and the progress against the deliverables. If the supplier does not want to provide that insight to mitigate your risk, you may be wise to look elsewhere.
When problems arise in a outsourcing situation, a solution is often sought in the details of the contract. What is not written can not be enforced. Therefore, you must carefully craft your contract to avoid getting to that problem point.
Question: There are several e-business models: Business to Consumer (B2C), Business to Business (B2B). What about Business to Government (B2G)? Is there a market to do e- business with government?
Answer: Although several governments have lagged behind the private sector in the rush to get on-line, I believe business-to-government e-commerce, known as B2G or G2B, is very big. Several private companies have recently begun hosting government web sites and building government virtual marketplaces. IBM recently collaborated with U.S Government to provide online consulting for government agencies and create government web sites to serve the needs of citizens. There is a dramatic increase in the government’s recognition of the value of putting things on the web and the value they can bring to its citizens. The Gartner Group estimates spending on e-commerce by federal, state, and local governments will increase from $1 billion in 2000 to more than $16 billion in 2010. It is possible that the B2G market may become the largest e-commerce market in the world possibly reducing the government’s need for administrative staff and also generating revenue for companies that build and host government sites.
Question: Does the U.S. remains number one in software or has India passed us by? Please keep us up to date on these trends.
Answer: At this time, the U.S still has the lead but India is not far behind. If the trend continues, in the next few years, U.S and India could be very close.
Here are some data: India’s software exports in 2007 totaled $60 billion U.S. dollars with 70% of the exports going to the U.S. Today India’s companies such as TCS, H.C.L, Wipro, and Infosys Technologies are well known in the U.S. and in the world. India’s software exports were 24% of the worldwide business. It is estimated that in 2010 India’s exports will increase to approximately $100 billion, which will amount to 30% share of worldwide software business. By the way, Indian software engineers’ salaries also increased significantly in the past several years due to high demand. Many no longer want to do just programming but demand a bigger role in project management, system design, and large-scale integration and they already outsource software development to other lower cost countries.
Question: Why do we need to document a process? Is it a value-added activity or just to satisfy the CMMI requirements?
Answer: Software Engineering is a knowledge intensive business. However, this knowledge is not documented for others to use but kept in the heads of developers. When they leave, they take their knowledge with them and the undocumented knowledge is lost. Knowledge is the asset, the value, and the intellectual property of the company. Without documentation, the company does not even know what kind of knowledge they lost.
Let’s imagine that we can reuse all the experience and knowledge of how to successfully develop software or manage projects. How powerful and desirable that would be! Capturing knowledge is what process documentation is all about—how to represent and store knowledge and what tools to use to acquire, store, search, and retrieve knowledge and experience effectively and efficiently.
By the way, this questions and answers in this website is another way of documenting and sharing my knowledge with all of you.
Question: Why do we need periodic review of improvement activities? Is it micro management?
Answer: No, it is not micro management but an effective way of monitor organizational investment in process improvement. Periodic reviews of improvement activities enables manager to assess improvement progress, critical performance issues, analyze improvement results for fine-tuning and optimizing the business, gain visibility into improvement tasks and their impact on organization’s performance.
Đáp: Tác nhân thay đổi không phải là chức danh hay chức vụ và SEPG không phải là câu lạc bộ dành riêng. Bất kì ai cũng đều có thể là tác nhân thay đổi. Khi bạn để ý thấy cái gì đó có thể được cải tiến trong tổ chức của mình, bạn có cơ hội để là tác nhân thay đổi. Cấp quản lí bao giờ cũng đánh giá cao những người sẵn lòng giúp cải tiến qui trình.
Tuy nhiên, khi bạn nhận diện một nhu cầu thay đổi, xin lấy các bước học thêm về qui trình. Có thông tin thích hợp là rất quan trọng để ra quyết định đúng bởi vì đôi khi một khuyến cáo thay đổi có thể thất bại khi người đưa ra gợi ý nhưng không đầu tư đủ thời gian để hiểu tại sao mọi sự được làm theo cách đó. Bạn cần điều tra xem ai sẽ bị ảnh hưởng bởi thay đổi này và giá cho việc làm thay đổi là gì. Bạn cần lắng nghe mọi quan điểm, và xem xét hỏi ý kiến mọi người trước khi đưa ra khuyến cáo của mình. Hãu học từ kinh nghiệm của người khác và bao giờ cũng lễ phép, kính trọng và trên hết, kiên trì.
Hỏi: Vai trò của người phát triển phần mềm là gì trong các hoạt động cải tiến mức 3?
Đáp: Người phát triển phần mềm là người đóng góp chính vào việc cải tiến qui trình ở bất kì mức nào. Không có họ việc cải tiến sẽ không bao giờ xảy ra.
Người phát triển cần tuân theo các thủ tục phần mềm và chuẩn trong tổ chức để đảm bảo sự nhất quán. Họ cần chứng tỏ hiểu biết sâu về phương pháp và công cụ được dùng trong tổ chức cũng như khuôn khổ CMMI.
Ở mức 3, Qui trình phần mềm chuẩn của tổ chức – Organization Standard Software Process (OSSP) tồn tại để cung cấp hướng dẫn và đảm bảo sự nhất quán. Người phát triển cần tuân theo qui trình phần mềm đươc dự án xác định, đó là phiên bản được điều chỉnh của qui trình được xác định OSSP. Họ cần đảm bảo rằng sản phẩm phần mềm mà họ tạo ra là có chất lượng cao nhất có thể có bằng việc loại bỏ lỗi (Tiến hành nhiều phiên kiểm điểm, giám định). Họ cần tuân theo kĩ thuật nào đó để đảm bảo tuân thủ chính xác và kịp thời về dữ liệu kích cỡ, nỗ lực, lịch biểu và lỗi gửi cho Người quản lí dự án. Vì cải tiến là liên tục, người phát triển cũng cần tham gia vào việc cải tiến OSSP bằng việc đệ trình các yêu cầu thay đổi và đề nghị các ý tưởng cải tiến cho qui trình cải tiến tổ chức để làm cho nó thành chỗ làm việc tốt hơn.
Hỏi: Tổ chức của tôi mới bắt đầu dùng CMMI và tôi đang thành lập SEPG. Tôi nên dùng cách tiếp cận nào?
Đáp: Có nhiều cách tiếp cận tới việc bắt đầu cải tiến qui trình bằng việc dùng CMMI nhưng sau đây là khuyến cáo của tôi:
Là một thành viên SEPG, bạn cần đảm bảo rằng mọi hoạt động cải tiến đều được gióng thẳng với mục đích, mục tiêu kinh doanh của tổ chức. Rồi bạn có thể điều phối, tạo điều kiện cho các hoạt động cải tiến giữa các nhóm hay dự án và theo dõi các hoạt động nàu bên trong SEPG.
Nếu tổ chức của bạn lớn (trên 1,000 người) bạn có thể cần chia nó thành nhiều nhóm nhỏ hơn dựa trên miền hay nghiệp vụ chuyên môn và cải tiến từng nhóm mỗi lúc. Làm mọi thứ ngay một lúc là khó và rủi ro, vì thay đổi yêu cầu nỗ lực và cam kết lớn.
Trước khi bạn bắt đầu, bạn cần có cuộc họp với lãnh đạo cấp cao để thảo luận về cải tiến qui trình, ước lượng tài nguyên và nỗ lực, mục đích và mong đợi, đầu tư và thu hồi vốn đầu tư v.v. Chỉ khi bạn có cam kết dài hạn (vài năm) từ quản lí cấp cao, bạn mới có thể bắt đầu hoạt động cải tiến.
Bước tiếp sẽ là huấn luyện mọi người quản lí liên quan tới hoạt động cải tiến để thu được sự hỗ trợ của họ. Họ phải hiểu, cam kết và hỗ trợ điều bạn đang lập kế hoạch thực hiện là chỉ khi tất cả các nhà quản lí đồng ý với bạn thì bạn mới có thể bắt đầu việc huấn luyện thêm cho mọi người trong tổ chức. Bạn cần giải thích qui trình cải tiến bắt đầu từ việc thu được cam kết của họ, tiến hành đánh giá để biết tổ chức đang ở đâu cùng những điểm mạnh điểm yếu và kế hoạch hành động có việc đo. Sau khi mọi người thực sự hiểu cải tiến tất cả là gì và đồng ý hỗ trợ bạn thì bạn có thể bắt đầu hoạt động đánh giá, xây dựng kế hoạch hành động và triển khai các hoạt động cải tiến. Bạn cũng cần thiết lập cách đo tuyến cơ sở theo mục đích kinh doanh và bắt đầu theo dõi mọi hoạt động cải tiến. Sau rốt, bạn cần dữ liệu chứng minh rằng hoạt động cải tiến quả thực tạo ra khác biệt.
Hỏi: Khi nào chúng tôi cần thu thập thực hành tốt nhất cho Thư viện tài sản qui trình (PAL)?
Đáp: Bất kì lúc nào bạn thấy “thực hành tốt nhất” hay cái gì đó có tác dụng trong tổ chức của mình. Về căn bản, Thư viện tài sản qui trình (PAL) nổi lên khi tổ chức đi từ mức 1 lên mức 2. Chừng nào còn có “thực hành tốt nhất,” người ta còn phải thu thập và để chúng vào chỗ mọi người có thể chia sẻ và sử dụng.
Hỏi: Tại sao phải bận tâm tới tuyển tập qui trình cũ, cái giới hạn sự sáng tạo cá nhân như CMMI khi phần mềm là qui trình canh tân cao?
Đáp: Ngược lại, tôi tin CMMI là khuôn khổ mạnh tạo khả năng cho tổ chức sản xuất ra sản phẩm tốt hơn trong khi cung cấp cho nhân viên của nó môi trường làm việc được cải thiện.
CMMI không phải là qui trình được yêu cầu. Không có các bước, hay các hoạt động, mà phải tuân theo nghiêm ngặt. Cải tiến qui trình thực sự là việc thích nghi và hành động sửa chữa bằng việc dùng thông tin dự án quá khứ. Bằng việc tuân theo một qui trình được xác định rõ, tổ chức có thể giảm sự không chắc chắn và rủi ro. Đó là lí do tại sao tổ chức phải làm tài liệu và trắc nghiệm điều được làm. Nếu cái gì đó đi sai đối với dự án, thông tin sẽ được dùng trong dự án tiếp để tránh việc phạm phải cùng sai lầm.
Vài năm trước, tôi đã làm việc trong một tổ chức không tuân theo qui trình. Khi một dự án kết thúc, tài liệu thiết kế không tương ứng với sản phẩm phần mềm, và không có thời gian nào để làm tài liệu hay sửa vấn đề nào được tìm thấy. Khi dự án mới bắt đầu, tổ mới dùng tài liệu cũ như tham chiếu thiết kế, và do đó, đã lặp lại nhiều sai lầm từ dự án trước. Không có qui trình chính thức để trắc nghiệm và kiểm nghiệm thiết kế, để làm quản lí cấu hình, hay để quản lí yêu cầu, cùng sai lầm tiếp tục bị phạm phải trên từng và mọi dự án. Những lỗi này đã tạo ra nhiều vấn đề hơn và nhiều chi phí hơn việc đơn giản cải tiến bằng cách cập nhật tài liệu thiết kế.
Liên quan tới tính sáng tạo cá nhân, tôi tin việc phát triển phần mềm tương tự với qui trình xây dựng nhà. Tính sáng tạo của kiến trúc sư có bị giới hạn bởi các qui tắc và qui chế luật lệ xây dựng không? Có thể có chút ít vì kiến trúc sư phải tuân thủ theo những qui tắc nào đó như an toàn, các đặc trưng của vật tư được dùng, mối quan tâm tới thẩm mĩ, vân vân. Tính sáng tạo, tri thức và kĩ năng là thuộc tính cá nhân nhưng mọi người có đánh mất chúng bởi vì họ tuân theo qui trình không? Qui trình có chế áp cách người ta nghĩ hay sáng tạo không? Tôi không nghĩ vậy.
Hỏi: Cuộc họp của chúng tôi về cải tiến qui trình không hiệu quả. Phần lớn mọi người dành thời gian tranh cãi lẫn nhau. Làm sao tôi tạo ra được môi trường mà mọi người có thể chia sẻ mọi thứ một cách hiệu quả?
Đáp: Có kĩ thuật tên là: “chia sẻ 10 phút” chính là cơ hội để mọi người nói về cải tiến qui trình. Qui tắc là:
1) Mọi chủ đề đều phải hội tụ chỉ vào cải tiến qui trình
2) Từng người được tối đa mười phút nói.
3) Sẽ có bộ đếm thời gian. Khi hết mười phút, diễn giả phải dừng. Nếu chuông rung vào giữa câu, chúng ta sẽ dừng ở đó. Các đối thoại sau cuộc họp để kết thúc chủ đề được khuyến khích.
4) Ưu tiên cho việc nói:
a) Mọi người phải ghi tên mình vào danh sách trước khi họp.
b) Mọi người sẽ nói theo thứ tự đã đăng kí. Vì đây không phải là bài trình bày, không có máy chiếu, các tờ chiếu không được phép, chỉ đối thoại vô tư để chia sẻ điều bạn đã biết.
5) Nếu không còn ai nói, chúng ta có thể quay lại diễn giả trước đó hay để mở cho bất kì ai.
6) Vui vẻ, chia sẻ nhiều, và làm việc cải tiến xảy ra.
Hỏi: Tổ chức của tôi được xác nhận ISO 9001 vài tháng trước đây và hiện thời chúng tôi đang làm việc về CMMI với hi vọng đạt tới ít nhất cũng là CMM mức 2. Đạt tới CMM mức 2 sau kiểm định ISO 9001 là dễ hơn hay có cách đi vòng nào khác?
Đáp: Nhiều người nghĩ rằng đạt tới mức 2 dễ hơn khi bạn được xác nhận ISO 9001 nhưng có một số vấn đề cần được trả lời:
– Ai chịu trách nhiệm về chất lượng? (QA hay dự án)
– Có cách nào khác để phát triển phần mềm thay vì tuân theo bản kế hoạch chất lượng mà mọi người tuân thủ nghiêm ngặt một số thủ tục tài liệu nào đó.
– Ai nên chịu trách nhiệm cho thủ tục phần mềm? Ai sở hữu chính sách, kế hoạch, và qui trình (Đó là QA, dự án hay cấp quản lí?) và ai nên viết chúng ra?
– Cái gì “thực sự” là thủ tục, chính sách, kế hoạch chất lượng, và qui trình?
– Tổ chức phải dịch chuyển tư duy từ, “Chúng ta đã qua được kiểm định ISO 9001″ sang “Chúng ta phải cải tiến cách chúng ta quản lí dự án phần mềm của mình.”
Hỏi: Có tương quan nào giữa Quản lí hiệu năng và miền qui trình bù trong People CMM mức 2 và PA phân tích tri thức và kĩ năng ở mức 3?
Đáp: Từng người phải có mục đích cải tiến cá nhân được làm tài liệu trong kế hoạch hiệu năng của mình nhận diện ra điều họ muốn cải tiến. Họ nên bao hàm cả mục đích đào tạo cá nhân của mình, điều tương quan với mong muốn của họ để mở rộng phân công và hoạt động.
Trong kiểm điểm hiệu năng với người giám sát, nhân viên nên thảo luận về trách nhiệm, chức vụ và đảm nhiệm hiện thời của mình và cách nó tương quan với mục đích cải tiến cá nhân.
Một cách lí tưởng, kết quả của kiểm điểm hiệu năng nên được dùng như một trong nhiều tiêu chí cho bù đắp tương lai. Trọng tâm huấn luyện của tổ chức nên tổ hợp mục đích huấn luyện cá nhân vào trong kế hoạch huấn luyện cho tổ chức. Ham muốn cá nhân để mở rộng phân công và hoạt động nên được dùng trong việc chuẩn bị báo cáo mà người quản lí và người lãnh đạo dùng cho việc lựa cán bộ tương lai cả cho các chức năng toàn thời và bán thời.
Hỏi: Tôi rất ngạc nhiên là tổ chức của tôi được thẩm định ở mức 2. Tôi đã không để ý thay đổi hay cải tiến nào. Làm sao điều đó lại xảy ra?
Đáp: Đôi khi đạt được mức CMMI dường như xuất hiện qua đêm. Nhưng thay đổi bao giờ cũng xảy ra, từng tí một, qua một thời kì. Mọi người thay đổi với tỉ lệ khác nhau, nhưng chung cuộc, toàn bộ tổ chức quả có thay đổi. Mức 2 chỉ mới là bắt đầu, bước đầu tiên của cuộc hành trình dài. Bạn có lẽ không thấy mấy khác biệt giữa hôm nay và hôm qua nhưng nếu tổ chức của bạn tiếp tục theo tiến trình của nó, mọi người trong tổ chức sẽ có khả năng thấy những thay đổi có ý nghĩa trong vài năm kể từ bây giờ.
Hỏi: CMMI yêu cầu phương pháp luận nào? Về công cụ hay vòng đời phát triển phần mềm (SDLC) thì sao?
Đáp: CMMI không yêu cầu phương pháp luận nào nhưng nó nhấn mạnh rằng tổ chức đi theo một phương pháp luận. CMMI không ra lệnh phải dùng bất kì công cụ nào nhưng tổ chức phải lựa công cụ nào nó cần để phát triển và duy trì phần mềm. CMMI cũng không nhấn mạnh vào bất kì vòng đời phát triển phần mềm đặc thù nào (SDLC) nhưng tổ chức phải quyết định dùng SDLC thích hợp.
Điều CMM thực sự ngụ ý là ở chỗ tổ chức lựa bất kì công cụ nào, bất kì vòng đời phát triển phần mềm (SDLC) nào, và phương pháp luận để dùng và tuân theo chúng, dùng chúng, đo chúng và cải tiến chúng. Thực tế, tổ chức có thể có nhiều phương pháp luận, công cụ, hay SDLC cho từng kiểu dự án.
Hỏi: Tôi không hiểu tại sao chúng ta cần hội tụ quá nhiều vào việc tuân theo qui trình tài liệu và dùng nó qua tất cả năm mức. Xin thầy giải thích.
Đáp: Qui trình tài liệu là đống giấy tờ chừng nào mọi người còn chưa dùng nó để làm cái gì đó. Tài liệu là bước đầu tiên nhưng không phải là đích đến cuối cùng. Về căn bản, ở mức 2 các dự án có thể dùng các qui trình đã được làm tài liệu của mình. Tuy nhiên, ở mức 3 dự án nên dùng Qui trình chuẩn phần mềm của tổ chức Organization Software Standard Process (OSSP). Qui trình chuẩn không xuất hiện “từ trời xanh” như phát minh của một nhóm ở đâu đó. Nó nên tới từ những thực hành tốt nhất: Thực hành tốt nhất được thu thập từ nhiều dự án và được cất giữ trong thư viện tài sản qui trình (PAL) để các dự án khác dùng lại. Những tài sản dùng lại này thiết lập nên sự kiện là tổ chức có các qui trình chuẩn được mọi dự án sử dụng và do đó nó quản lí nhất quán tất cả các dự án của nó tương ứng. Nó cũng lập ra giai đoạn thu thập cách đo trên việc dùng các tài sản đó: Chúng tốt thế nào? Chúng chính xác thế nào? Điều này trở thành cơ sở cho việc cơ cấu tổ chức để thực sự đo hiệu năng qui trình và sản phẩm tại mức trưởng thành tiếp (mức 4). Cách đo được dựa trên việc dùng các tài sản cơ sở này ngang qua mọi dự án, nó cho phép so sánh kết quả của các dự án khác nhau qua thời gian, điều hình thành nên cơ sở cho kiểm soát qui trình thống kê. Tại mức 4 các dự án đều được quản lí theo những mục đích được mong đợi nào đó (tức là không có việc trượt lịch biểu hơn vài ngày, không có nhiều hơn X lỗi) và dữ liệu được thu thập sẽ được dùng để xem tài sản nào là nguyên nhân của biến thiên. Những tài sản gây ra biến thiên là ứng cử viên cho việc cải tiến ở mức 5 trong Canh tân công nghệ và Quản lí thay đổi và Quản lí thay đổi qui trình nơi mà công cụ, phương pháp và qui trình được cập nhật để làm giảm biến thiên.
Hỏi: Khách hàng của tôi muốn có tốc độ tối đa nhưng chúng tôi muốn thực hiện với chất lượng và hiệu quả. Làm sao thầy cân bằng được điều này?
Đáp: Đúng là cả hai phía đều có những cái nhìn khác nhau. Chìa khoá cho bạn và khách hàng của bạn là nhận ra điều này và phát triển hiểu biết về điều này dẫn lái tới điều kia. Bạn không phải đồng ý với mọi thứ, nhưng có giá trị trong sự nhạy cảm được tăng cường. Làm điều này có thể nảy sinh sự bù trừ nào đó mà nếu không thế thì có thể không có được (chẳng hạn, đổi chi phí lấy tốc độ). Bạn không thể lúc nào cũng theo cách của mình mà bạn có thể giáo dục khách hàng về tại sao mọi sự là theo cách của chúng.
Hỏi: Trong vài tháng qua, nhiều người đã viết thư cho tôi và bày tỏ thất vọng về một số quyết định đẩy họ và tình huống xấu. Họ đã được trao mệnh lệnh cải tiến qui trình để đạt tới một mức trước ngày nào đó, vậy mà mọi thứ khác lại có ưu tiên cao hơn cải tiến qui trình.
Đáp: Chúng ta hãy nhìn vào tình huống này và vai trò của tác nhân thay đổi (thành viên của SEPG):
Tác nhân thay đổi hỗ trợ để cung cấp nhiệt tình, kĩ năng và chiều hướng cần có để vượt qua sự chống cự và làm thay đổi xảy ra.
Đầu tiên, chúng ta hãy thảo luận về vấn đề nhiệt tình: Nếu bạn không nhiệt tình với điều bạn làm thì tác nhân thay đổi không phải là việc dành cho bạn. Tôi giả sử rằng khi chấp nhận việc của SEPG, bạn có thái độ này trừ phi bạn bị “phân công” cho việc mà bạn không hề muốn. Trong trường hợp đó, bạn cần có thảo luận lâu với người quản lí của bạn.
Thứ hai, ta hãy nhìn vào vấn đề kĩ năng. Tôi mạnh mẽ tin tưởng rằng thành viên SEPG nên được tuyển mộ — không được phân công. Điều này nghĩa là cấp quản lí không nên phân công người cho vai trò này chỉ bởi vì họ có đó và sẵn có mà phải chọn lựa cẩn thận người có phẩm chất, người có thể tạo ra khác biệt. Để thành công, thành viên SEPG cần diện rộng kinh nghiệm phần mềm. Ít nhất cũng nhiều năm phát triển và bảo trì phần mềm. Kinh nghiệm này cho phép thành viên SEPG hiểu những thay đổi được cần tới cho các dự án cũng như trong toàn tổ chức và, hiểu tác động của những thay đổi nào đó với các dự án và trên tổ chức. Trong nhiều năm quá khứ, tôi đã huấn luyện nhiều thành viên SEPG và việc huấn luyện của tôi yêu cầu hai năm tham gia các lớp tập huấn và thực hành, đó là rất nhiều việc huấn luyện và tôi hi vọng nhiều người trong các bạn sẽ có khả năng áp dụng điều bạn đã học cho tổ chức của bạn.
Tất nhiên, cải tiến qui trình không bao giờ là nhiệm vụ dễ dàng! Bạn cần động viên cán bộ, tạo ra nhiệt tình, và tiếp sinh lực cho toàn tổ chức. Bạn cần làm cho tổ chức hiểu cả tầm nhìn và hiện thực hiện thời liên quan tới tầm nhìn đó. Một số trong những hiểu biết này tới khi bạn chuyển các kết quả thẩm định (điểm yếu và điểm mạnh) vào kế hoạch hành động. Bạn cần rất sáng tạo trong việc tìm ra giải pháp cho những điểm yếu của dự án và tổ chức. Bạn cũng phải dẫn nhịp để thay đổi xuất hiện trong tổ chức bởi vì nếu nhịp thay đổi quá chậm, tiến bộ sẽ bị giới hạn; trong khi nhịp quá nhanh sẽ bị ngắt quãng và tự thất bại. Một người SEPG có kĩ năng phải có khả năng lập kế hoạch và quản lí cải tiến qui trình coi như nó là dự án phần mềm.
Watts Humphrey, tác giả của CMM đã nói: thành viên SEPG “phải là người quản lí thông thái với năng lực được chứng minh để làm cho mọi sự xảy ra, người tôn trọng các nhà chuyên môn dự án, và hỗ trợ cho quản lí cấp cao.”
Cho nên thay vì chỉ tay vào ai đó khác, chúng ta hãy tự hỏi mình vài câu hỏi hắc búa. Bạn, xem như một thành viên của SEPG, bằng việc chọn lựa, liệu có phẩm chất và nền tảng cần thiết để hướng chương trình cải tiến qui trình đi tới kết luận thành công trong tổ chức của bạn không? Bạn có phải là người có thể làm cho mọi sự xảy ra không? Bạn có tôn trọng người lãnh đạo dự án và người quản lí tổ chức để cho bạn có thể thực hiện các nhiệm vụ được yêu cầu ở bạn như tác nhân thay đổi không? Bạn có nhiệt tình cần thiết để làm cho tổ chức thay đổi không? Dễ trách ai đó hay cái gì đó khi mọi sự không làm việc theo cách bạn muốn nhưng có những lúc bạn cần nhìn sâu vào trong bản thân mình và hỏi những câu hỏi hắc búa, không chỉ một lần hay hai lần mà mọi ngày.
—-English version —-
Question: I am not a “Change agent” or SEPG member. How could I help process improvement?
Answer: Change agent is not a title or position and SEPG is not an exclusive club. Anyone can be a change agent. When you notice something that can be improved in your organization, you have an opportunity to be a change agent. Management always appreciates people who are willing to help in improving the process.
However, when you identify a need for change, please take steps to learn more about the process. Having adequate information is very important to make good decision because sometimes a recommendation for a change can fail when people makes suggestions without investing enough time in understanding why things are done that way. You need to investigate on who would be affected by the change you are suggesting and what the cost of making the change would be. You need to listen to all points of view, and consider asking everybody before making your recommendations. Learn from the experience of others and always be polite, respectful, and most of all, persistent.
Question: What is the role of software developers during the level 3 improvement activities?
Answer: Software developers are key contributors in process improvement at any levels. Without them improvement will never happen.
Developers need to follow software procedures and standard in the organization to ensure consistency. They need to demonstrate an in-depth understanding of methods and tools used in the organization as well as the CMMI framework.
At level 3, the Organization Standard Software Process (OSSP) exists to provide guidance and ensure consistency. Developers need to follow the project defined software process that is a tailored version of the OSSP defined process. They need to ensure that the software product that they create is of highest possible quality by removing defects (Conduct more reviews, inspections).They need to follow certain technique to ensure accurate and timely submittal of size, effort, schedule, and defect data to the Project Manager. Since improvement is continuous, developers also need to participate in the improvement of the OSSP by submitting change requests and propose improvement ideas to the organization improvement process to make it a better place to work.
Question: My organization just starts to use the CMMI and I am forming a SEPG. What approach should I use?
Answer: There are many approaches to start process improvement using CMMI but following is my recommendation:
As a SEPG member, you need to ensure that all improvement activities are aligned with organization business goals, objectives. Then you may want to coordinate, facilitate improvement activities between groups or projects and tracking these activities within your SEPG.
If your organization is large (Over 1,000 people) you may want to divide it into smaller groups based on specific domain or business and improve one group at a time. It is difficult and risky to do everything all at once, since changes require significant efforts and commitment.
Before you start, you need to have a meeting with senior management to discuss the improvement process, resources and effort estimates, goals and expectations, investment and return on investment etc. Only when you have long term commitment (several years) from senior management, you may start improvement activities.
The next step would be training all managers regarding the improvement activities to obtain their support. They must understand, commit and support what you are planning to do and only when all managers agreed with you then you may begin the additional training to people in the organization. You need to explain the improvement process starting with obtain their commitment, conduct appraisal to know where the organization is as well as the strengths and weaknesses and the action plan with measurements. After people really understand what the improvement is all about and agree to support you then you may start the appraisal activities, develop action plans and deploy improvement activities. You also need to establish a baseline measurement against the business goals and begin tracking all improvement activities. After all, you need data to prove that improvement activities indeed do make the difference.
Question: When do we need to collect best practices for the Process Assets Library (PAL)?
Answer: Anytime you find “Best practices” or something that works in your organization. Typically, Process Assets Library (PAL) emerges when organization going from Level 1 to Level 2. As long as there are “Best practices”, one must collect and deposit them in a place where people can share and use.
Question: Why bother with an old collection of process that limits personal creativity such as the CMMI when software is highly innovation process?
Answer: On the contrary, I believe CMMI is a powerful framework that enables an organization to produce better products while providing its employees with an improved working environment.
The CMMI is not a required process. There aren’t steps, or activities, that must be strictly followed. Process improvement is really an adaptation and corrective actions using past project information. By following a well-defined process, organization can reduce the uncertainties and risks. That is why the organization must document and verify what is done. If something goes wrong for a project, the information will be used on the next one to avoid making the same mistakes.
Few years ago, I have worked in an organization that didn’t follow a process. When a project ended, the design documentation didn’t correspond to the software product, and there wasn’t any time to document or correct any of the found problems. When a new project began, the new team used the old documentation as a design reference and, therefore, repeated many mistakes from the previous project. Without a formal process to verify and validate the design, to do configuration management, or to manage requirements, the same mistakes continued to be made on each and every project. These errors ultimately created more problems and cost more than it would have cost to simply improve by updating the design documentation.
Regarding personal creativity, I believe develop software is similar to the process of a building construction. Is the architect’s creativity limited by rules and building code regulations? Maybe a little since the architect has to comply with certain rules such as safety, the characteristics of the materials used, be concerned with aesthetics, and so on. Creativity, knowledge and skills are personal attributes but do people lose them because they are following a process? Does a process dictate how a person thinks or creates? I do not think so.
Question: Our meeting on process improvement is not effective. Most people spend time arguing with each other. How do I create an environment where people can share things effectively?
Answer: There is a technique called: “10 minutes sharing” which is an opportunity for people to talk on process improvement. The rules are:
1) All subjects must be focused on process improvement activities only
2) Each people get a maximum of ten minutes to talk.
3) There will be a timer. When the ten minutes are up, speaker must stop. If the bell rings in mid-sentence, we will stop there. Conversations after meeting to finish a subject are encouraged.
4) Priority for speaking:
a) People must put their name on the list before the meeting.
b) People will speak in the order that they sign up. Since this is not a presentation, no projector, slides is allowed, only candid conversation to share what you learned.
5) If no one is left to speak, we may go back to an earlier speaker or open to anyone.
6) Have fun, share a lot, and make improvement happen.
Question: My organization was ISO 9001 certified few months ago and currently we are working on the CMMI hoping to achieve at least CMM level 2. Is it easier to achieve CMM level 2 after ISO 9001 audit or the other way around?
Answer: Many people may think that it is easier to achieve Level 2 when you are ISO 9001 certified but there are certain issues that need to be answered:
– Who is in charge for quality? (QA or the project)
– Is there other way to develop software rather than follow a quality plan require that people to strictly follow certain number of documented procedures.
– Who should be responsible for software procedure? Who own policy, plan, and process (Is it QA, project, or management?) and who should write them?
– What are “really” a procedure, policy, quality plan, and process?
– The organization must shift the thinking from, “We’ve got to pass the ISO 9001 audit” to “We have to improve the way we manage our software projects.”
Question: What correlation between Performance Management and Compensation PAs in People CMM level 2 and Skills and knowledge analysis PA at Level 3?
Answer: Each person should have the individual improvement goals documented in their performance plan identify what they want to improve. They should include their individual training goals that correlate with their desire to broadening assignment and activities.
During performance review with their supervisor, the employee should discuss his or her current responsibilities, position and accountabilities and how it correlates with the individual improvement goals.
Ideally, the result of the performance review should be used as one of many criteria for future compensation. The organization training focal should incorporate all individual training goals into a training plan for the organization. The individual desire to broadening assignments and activities should be used in preparing a report that managers and leaders use for future staffing both part-time and full-time functions.
Question: I was very surprised that my organization was assessed at level 2. I did not notice any changes or improvements. How does it happen?
Answer: Sometime achieving a CMMI level seems to occur overnight. But change is always happening, little by little, over a period of time. People changes at different rates, but eventually, the entire organization does change. Level 2 is only the beginning, the first step of a long journey. You probably do not see much different between today and yesterday but if your organization continues to follow its course, people from the organization will be able to see significant changes few years from now.
Question: Which methodology does the CMMI required? What about tools or software development life cycle (SDLC)?
Answer: The CMMI does not require any methodology but insists that the organization following one. CMMI does not dictate any tool to use but the organization must select whichever tool it need to develop and maintain software. The CMMI also does not insist on any particular software development life cycle (SDLC) but the organization must decide which appropriate SDLC to use.
What the CMM really implies is that the organization selects whatever tools, software development life cycle (SDLC), and methodology to use and follow them, use them, measure them and improve on them. In fact, the organization may have more than one methodology, tool, or SDLC for each type of project.
Question: I do not understand why we need to focus too much on following a document process and the usage of it throughout the five levels. Please explain.
Answer: A document process is a heap of paper unless people use it to do something. Document is the first step but not the final destination. Basically, at level 2 projects can use their own documented process. However, at level 3 projects should use the Organization Software Standard Process (OSSP). The standard process should not appear “out of the blue sky” as the invention of a group somewhere. It should come from best practices: The best process collected from several projects and stored in the process asset library (PAL) for re-use by other projects. These re-usable assets establish the fact that the organizational has standard processes to be used by all projects and therefore it is consistently managing all of its projects accordingly. It also sets the stage for the collection of measurements on the use of those assets: How good are they? How accurate are they? This becomes the basis for setting up the organization to truly measure process and product performance at the next maturity level. (Level 4) The measurements being based on the use of these basic assets across all projects, it allows a comparison of the results of different projects over time which forms the basis for statistical process control. At level 4 projects are managed to certain expected goals (i.e. No schedule slippage more than a few days, no more than X defects) and data collected will be used to see which assets are the cause of variations. Assets causing variation are candidates for improvement at level 5 in Technology innovation and Change Management and Process Change Management where tools, methods and processes are upgraded to reduce the variation.
Question: My customer wants maximum speed but we want to perform with quality and efficiency. How do you balance this?
Answer: It is true that both sides have different views. The key for you and your customer is to recognize this and to develop an understanding of what is driving the other. You don’t have to agree to everything, but there is value in the heightened sensitivity. Doing this may result in certain trade- offs that might not otherwise have come up (for example, trading cost for speed). You can’t always have your way but you can educate your customer on why things are the way they are.
Question: In the past few months, several people have written to me and expressed frustration over some decisions for placing them in a bad situation. They have been given an order to improve the process to achieve a level by a certain date, yet everything else has more priority than the process improvement.
Answer: Let’s look at the situation and the roles of the change agent (SEPG members):
A change agent supposed to provide the enthusiasm, skills, and direction needed to overcome resistance and make change happen.
First, let’s discuss the enthusiasm issue: If you are not enthusiasm about what you do then change agent is not a job for you. I assume that when accepting a SEPG job, you do possess this attribute unless you were “assigned” the job you never wanted. In that case, you need to have a long discussion with your manager.
Second, let’s look at the skills issue. I strongly believe that SEPG member should be recruited — not assigned. This means that management should not assign people to this role just because they are there and available but carefully select qualified people who can make the difference. To be successful, a SEPG member needs a wide breadth of software experience. At least, several years in develop and maintain software. This experience allows the SEPG member to understand the changes that are needed on projects as well as across the organization and, to understand the impact of certain changes on projects and on the organization. In the past several years, I have trained many SEPG members and my training required two-year of workshops and practicum, that is lots of training and I hope many of you will be able to apply what you learned to your organization.
Of course, process improvement is never an easy task! You need to motivate personnel, create enthusiasm, and energize the entire organization. You need to make the organization understand both the vision and the current reality relative to that vision. Some of this understanding comes when you translate assessment results (weaknesses and strengths) into action plans. You need to be very creative in finding solutions to project and organizational weaknesses. You also have to guide the pace at which change occurs in the organization because if the pace of change is too slow, progress will be limited; while too rapid a pace will be disruptive and self-defeating. A skilled SEPG should be able to plan and manage process improvement as though it was a software project.
Watts Humphrey, the author of CMM said: SEPG member “must be a knowledgeable manager with a demonstrated ability to make things happen, the respect of the project professionals, and the support of the top management”.
So instead of pointing the finger to somebody else, let’s ask ourselves some hard questions. Do you, as a SEPG member, by choice, have the qualities and background necessary to guide a process improvement program to successful conclusions in your organization? Are you the people who can make things happen? Do you have the respect of project leaders and organizational managers such that you can perform the tasks required of you as the change agent? Do you have the enthusiasm needed to make the organization change? It is easy to blame somebody or something when things do not work the way you wanted but there are times you need to look deeply into yourself and ask hard questions, not only once, or twice but everyday.
