CMMI-30 -Hạt giống tâm hồn

CMMI-30

GS John Vu03/06/2024 12:00

Hỏi: Một người không có kinh nghiệm phát triển phần mềm có nên được trao cho công việc của người quản lí dự án phần mềm không? Tại sao có và tại sao không?

Đáp: Đây là câu hỏi rất thú vị nhưng nó tuỳ thuộc vào dự án đặc thù và vào cá tính của người quản lí phần mềm. Với một số dự án, người quản lí dự án có kinh nghiệm miền chuyên môn còn quan trọng hơn nhiều so với người có kinh nghiệm phát triển phần mềm. Chẳng hạn, trong công nghiệp công nghệ sinh học, người quản lí dự án phần mềm thường là nhà sinh học hay nhà khoa học. Nếu họ là người lãnh đạo tốt, họ có thể dựa vào tri thức chuyên gia phần mềm của tổ mình để ra các quyết định kĩ thuật. Cùng điều này có thể được tìm thấy trong kinh doanh và tiếp thị nơi người quản lí doanh nghiệp giỏi có thể quan trọng hơn là người có kinh nghiệm phần mềm vì người đó có thể hội tụ vào khách hàng nhiều hơn, như đối lại với người hội tụ vào công nghệ.

Tuy nhiên, trong công nghiệp phần mềm, người quản lí dự án phần mềm phải hợp thức các quyết định kĩ thuật và chiều hướng cho dự án. Không có kinh nghiệm phát triển phần mềm, người quản lí có thể không đủ phẩm chất để làm hợp thức các quyết định như thế. Khi người quản lí dự án cần trao đổi với tổ phát triển, nếu người đó không có kinh nghiệm phần mềm, người đó có thể không thông thạo lắm về thuật ngữ của người lập trình và có thể không có khả năng chỉ đạo hiệu quả dự án. Người quản lí dự án phần mềm mà không có kinh nghiệm thì thường đánh giá kém về nỗ lực cần có để thực hiện các tính năng.

Nếu bên cạnh đó, người đó không giữ việc theo dõi nỗ lực, và người phát triển trong tổ của người đó là không tốt, dự án sẽ gần như chắc chắn bị trễ. Người quản lí không có kinh nghiệm có thể có khó khăn trong việc thu được kính trọng và tin cậy của người phát triển trong tổ. Điều này có thể ảnh hưởng tiêu cực tới tính năng động của tổ và năng suất của người phát triển.

Hỏi: Tôi tin điều công ti chúng tôi thực sự cần là thuê người thông minh thay vì cải tiến qui trình. Người thông minh có thể làm nhiều thứ đúng và không cần cải tiến. Thầy nghĩ sao?

Đáp: Bạn có thể cho tôi biết tôi tìm người thông minh ở đâu không? Họ có từ ‘thông minh” xăm lên trán không? Theo kinh nghiệm của tôi, người giỏi nhất cho bất kì công ti nào không phải là người thông minh nhất mà là người có khả năng học. Công nghệ ngày nay có cuộc đời sử dụng quãng 5 năm. Điều đó nghĩa là sự lỗi thời xuất hiện với tỉ lệ 20% một năm. Điều bạn biết hôm nay sẽ trở thành lỗi thời nhanh tới mức vài năm kể từ bây giờ bạn có thể đối diện với sự không chắc chắn trong an ninh việc làm.

Kẻ sống sót duy nhất là người học cả đời, người thường xuyên học và thay đổi sẽ giúp cho họ phát đạt trong thế giới thay đổi nhanh chóng này. Việc học không có nghĩa là bạn phải quay về trường học vì mọi người có thể học từ các hoạt động hàng ngày như chia sẻ những thực hành tốt nhất, phân tích dữ liệu, bài học rút ra sau khi hoàn thành dự án. Tổ chức phần mềm cung cấp rất nhiều cơ hội học tập vì nó đang thay đổi trên cơ sở hàng ngày. Chúng ta tất cả đều rất quen thuộc với các yêu cầu thay đổi hay công nghệ thay đổi. Tôi mạnh mẽ tin tưởng rằng nơi làm việc cung cấp môi trường học tập tốt nhất. Nếu chúng ta trở nên tự mãn và không cởi mở cho những thay đổi đang diễn ra, những hoạt động cải tiến như vậy, chúng ta sẽ bỏ lỡ cơ hội có nghĩa để học và tổ chức không làm được việc học sẽ không thể thành công trong dài hạn.

Để thành công trong thế giới đang thay đổi nhanh, doanh nghiệp phải có khả năng bao quát mọi thay đổi bằng việc trở thành “tổ chức học tập” bao giờ cũng học những điều mới bằng không sẽ dừng tồn tại. Tôi tin vai trò của SEPG là tạo ra tổ chức học tập này nơi những thực hành tốt nhất được thu thập và chia sẻ. Chúng ta phải tạo ra bầu không khí học tập, nơi mục đích học tập được xác định; kĩ năng và tri thức được nhận diện rõ ràng và được móc nối với chiến lược kinh doanh. Tất nhiên, khả năng học vẫn còn lại với cá nhân nhưng môi trường đúng và hệ thống thưởng có thể thúc đẩy việc học cả đời trong tất cả chúng ta.

Hỏi: Tổ chức của tôi đang lập kế hoạch đánh giá trong năm nay. Tuy nhiên, chúng tôi ở giữa chừng việc tái tổ chức chính. Người quản lí của chúng tôi đã ra đi và chúng tôi không biết ai sẽ là ông chủ mới. Chúng tôi có nên tiếp tục kế hoạch đánh giá của mình không?

Đáp: Không, tuyệt đối KHÔNG. Việc bắt đầu cải tiến trong khi tái tổ chức sẽ phản tác dụng bởi vì bất kì cải tiến nào thu được cũng sẽ rất khó duy trì qua một thời kì. Trong thời kì bất ổn này, việc đánh giá sẽ được coi là không gia tăng giá trị vì nó không thể phản ánh đúng sự trưởng thành năng lực của tổ chức. Vì người quản lí của bạn đã ra đi, bạn sẽ cần người quản lí mới. Xin hãy đợi chiều hướng mới.

Hỏi: Thầy ngụ ý gì khi thầy nói rằng thành viên SEPG cần là người trung thực?

Đáp: Tôi có thể đồng ý với bạn rằng thành viên SEPG KHÔNG trung thực khi người đó nói điều họ tin người khác muốn nghe, bỏ qua những vấn đề khó, gay go, trở nên quá kiêu ngạo hay che giấu đằng sau những cách nói kĩ thuật, và không diễn đạt cảm giác đúng của họ.

Hỏi: Tại sao thầy nhấn mạnh quá nhiều vào việc thu thập cách đo? Chúng tôi đã thu thập dữ liệu trong nhiều năm và nó bao giờ cũng là chuyện phí thời gian chẳng ai dùng dữ liệu theo bất kì cách nào?

Đáp: Trước khi cải tiến bất kì cái gì, bạn cần biết hiệu năng hiện thời hay thiết lập tuyến cơ sở để cho bạn có thể theo dõi tiến bộ của mình. Bằng việc thu thập dữ liệu về qui trình và sản phẩm phần mềm của mình, bạn hiểu những cơ hội cải tiến nằm ở đâu. Chẳng hạn, bạn có biết phần mềm của mình tốn bao nhiêu trong năm qua cho từng ứng dụng không? Ứng dụng nào đòi hỏi thời gian nhiều nhất của bạn? Bạn dành bao nhiêu thời gian cho việc kiểm thử? Bạn có thể ước lượng chính xác thế nào về các dự án tương lai? Con số trung bình các lỗi mà nhân viên của bạn đưa vào trên mỗi nghìn dòng mã là gì?

Chừng nào bạn chưa thu thập được các dữ liệu này và dùng dữ liệu này để cải tiến nó, bạn chẳng bao giờ biết bạn đã cải tiến được bao nhiêu. Tất nhiên, bạn không thu thập dữ liệu chỉ để thu thập nhưng phải dùng chúng để cải tiến mọi thứ. Cả việc thu thập và dùng dữ liệu đều là bản chất trong việc quản lí sản phẩm và qui trình phần mềm.

Hỏi: Tôi muốn là một thành viên SEPG nhưng không biết liệu có nghề nghiệp cho loại việc này trong công nghiệp không

Đáp: Bao giờ cũng có nghề nghiệp cho những người muốn tạo ra khác biệt. Thành viên SEPG là nhà chuyên môn muốn cải tiến cách tổ chức xây dựng sản phẩm phần mềm.

Để bắt đầu, bạn phải là người có kĩ thuật cao với nhiều kinh nghiệm phát triển phần mềm. Bạn phải có tri thức thấu đáo về vòng đời phần mềm, miền và công nghệ liên quan. Dùng kinh nghiệm của mình, bạn có thể giúp cho tổ chức cải tiến bằng việc chia sẻ ý nghĩ của bạn về cách mọi sự được thực hiện với người khác, thu thập những thực hành tốt nhất và đo tiến bộ. Bạn bao giờ cũng lấy cái nhìn hệ thống tổng thể, thám hiểm cách tiếp cận khác, làm tài liệu các qui trình và giải thích các miền qui trình then chốt. Trong loại công việc này, cuối cùng bạn sẽ thu được sự kính trọng và có vị trí của người lãnh đạo phần mềm hay nhà vô địch.

Hỏi: Chẳng thành vấn đề chúng ta cố gắng miệt mài thuyết phục khách hàng về ước lượng dựa trên dữ liệu lịch sử, họ bao giờ cũng khăng khăng rằng chúng ta phải làm mọi sự theo cách của họ. Có hi vọng nào không?

Đáp: Trong kỉ nguyên của nhanh chóng và phát triển phần mềm nhanh hơn đi đôi với các yêu cầu thay đổi thường xuyên, mối quan hệ giữa khách hàng và người phát triển đang trở thành rất mấu chốt.

Bằng cách nào đó chúng ta tiếp tục nhìn bản thân mình hoặc như trong vai trò của khách hàng hoặc của người phát triển nhưng chưa bao giờ là thành viên của tổ có mục đích và tầm nhìn chung. Trong nhiều năm, chúng ta được dạy hãy tin rằng khách hàng và người phát triển là các thực thể tách biệt, bị buộc làm việc trong một dự án. Qui tắc phân cấp này (Khách hàng bao giờ cũng đúng và thắng) sẽ tạo ra va chạm và chung cuộc thất vọng cho cả hai phía.

Đây là lúc chúng ta (khách hàng và người phát triển) nhận ra rằng hoặc có tình huống Thắng/Thắng hay Thua/Thua nhưng không có tình huống Thắng/Thua ở đây. Vai trò chính của người quản lí dự án là phải chắc chắn rằng dự án phục vụ cho nhu cầu của doanh nghiệp. Nếu dự án phần mềm thất bại, doanh nghiệp sẽ không thắng. Theo tinh thần đó, khách hàng và người phát triển phải cố gắng để làm việc cùng nhau hàng ngày – cho dù không có dự án đặc biệt để giải quyết.

Mọi người phát triển đều phải có ý thức về điều làm cho doanh nghiệp thành công, dù điều đó nghĩa là vật phẩm được bán, dịch vụ được cung cấp, hay mã được viết. Khi nghiệp vụ ngày càng trở nên phụ thuộc nhiều hơn vào công nghệ và công nghệ tan biến vào trong qui trình nghiệp vụ, sự phân biệt giữa hai điều này trở nên ngày càng không liên quan. Tôi thực sự tin làm việc cùng nhau để bắc cầu qua lỗ hổng này là niềm hi vọng duy nhất để xây dựng phần mềm tốt hơn.

Hỏi: Thầy làm thế nào cho thay đổi xảy ra khi chúng tôi dành phần lớn thời gian của mình vào làm tài liệu qui trình “hiện thế” và “cần thế” để cho chúng tôi có thể đạt được mức 2?

Đáp: Điều thông thường là người ta nghĩ tới thay đổi như một qui trình hai pha: “hiện thế” và “cần thế.” Nhiều người quản lí ưa thích đơn giản bảo mọi người điều họ mong đợi (cần thế) và để mọi chi tiết cho mọi người thảo ra. Kiểu như: “Tôi muốn ở mức 2 trước ngày nào đó.”

Nhiều người cũng tin nếu họ làm tài liệu qui trình “hiện thế,” thay đổi sẽ tự nhiên xảy ra. Họ không hiểu rằng trạng thái hiện thời hay “hiện thế” là môi trường thoải mái; con người là sinh linh theo thói quen sẽ chống lại thay đổi, bất kì thay đổi nào nhiều nhất có thể được.

Thay đổi là cuộc hành trình đi từ cái “hiện thế” sang cái “cần thế” và để làm cho thay đổi xảy ra, người quản lí cần tạo ra cảm giác khẩn thiết, sự không thoải mái cho bầu không khí “kinh doanh vẫn như thường” và hỗ trợ cho qui trình thay đổi xảy ra và cho phép mọi người điều chỉnh sang môi trường mới. Người quản lí cần giải thích sự hợp lí của lí do tại sao chúng ta cần thay đổi, nhấn mạnh vào chi phí của việc không thay đổi, hội tụ vào qui trình thay đổi và phải rõ ràng về điều sẽ xảy ra nếu mọi sự không làm việc (hậu quả và cơ hội bị mất) và cam kết làm cho sự việc xảy ra.

Hỏi: Tại sao bận tâm tới qui trình vì nó chỉ là có nghĩa là nhiều tài liệu, nó kiềm chế sáng tạo và làm phí hoài nỗ lực.

Đáp: Tôi tiếc là bạn cảm thấy qui trình chỉ có nghĩa là tài liệu. Qui trình phần mềm cũng có thể là:

a) Làm tài liệu mọi yêu cầu sau thoả thuận giữa người dùng và người phát triển.

b) Thu thập dữ liệu như ước lượng và thực tế và dùng chúng cho ước lượng tương lai.

c) Tuân theo thủ tục cấu hình khi thay đổi xảy ra hay khi đưa ra sản phẩm cho người dùng.

d) Tiến hành kiểm điểm mọi yêu cầu, thiết kế, mã nguồn và trường hợp kiểm thử.

e) Tạo ra bản kế hoạch đảm bảo chất lượng trong việc lập kế hoạch dự án để kiểm điểm sự tuân thủ chuẩn, theo dõi lỗi, tiến hành kiểm điểm.

Quan niệm qui trình giới hạn sáng tạo là dựa trên ý tưởng rằng có xung độ giữa tính sáng tạo và việc thoả mãn các mục tiêu nghiệp vụ dự án. Lịch biểu quá năng nổ nào đó có thể đưa dự án vào rủi ro nhưng về toàn thể, các mục đích nghiệp vụ có thể trong hài hoà hoàn hảo với tính sáng tạo. Người phát triển cảm thấy thú vị khi dự án hoàn thành trong thời gian và và chi phí và những điều này có thể được đạt tới bằng việc tạo ra qui trình cho phép cả hai phía làm việc cùng nhau với mục đích và tầm nhìn chung.

Hỏi: Hiển nhiên là cải tiến qui trình là rất quan trọng và là điều đúng nhưng tại sao chúng ta cần người bảo trợ? Sao không cứ làm nó đi?

Đáp: Người bảo trợ cho cải tiến qui trình sẽ đảm bảo rằng hoạt động cải tiến nhận được tài trợ, thời gian và hỗ trợ thích hợp nó cần cho nỗ lực thành công. Cải tiến là cuộc hành trình dài yêu cầu sự hỗ trợ lớn để duy trì tiến trình này. Không có người tài trợ có tầm nhìn với “đích” có ý nghĩa nó sẽ không có cơ hội đứng được.

Hỏi: Chúng tôi là công ti mới với mỗi một dự án lớn. Chúng tôi bắt đầu làm việc về pha yêu cầu lúc này nhưng muốn được đánh giá và hi vọng đạt tới ít nhất sự trưởng thành mức 3. Làm sao chúng tôi tiến hành được điều này, và liệu có thể làm mức 3 không?

Đáp: Tại sao bạn muốn có đánh giá? Nó là dành cho mục đích cải tiến hay chỉ để thoả mãn quan niệm tò mò liên quan tới mức trưởng thành? Tại sao mức 3 lại quan trọng cho bạn? Cải tiến qui trình là đầu tư yêu cầu cam kết của cấp quản lí và làm việc gian nan. Đánh giá chỉ là bắt đầu, thiết lập tuyến cơ sở cho cải tiến, không phải chỗ cuối của biến cố để tìm ra về một mức. Bạn có xét tới hậu quả của đánh giá không? Điều gì xảy ra nếu tổ chức của bạn được đánh giá ở mức 1 và không ở mức 3? Bạn và người của bạn có sẵn sàng chấp nhận điều đó không? Bước tiếp sẽ là gì? Bạn có tiếp tục nỗ lực cải tiến không? Cấp quản lí của bạn vẫn ủng hộ hoạt động cải tiến chứ? Từ quan điểm kĩ thuật, không thể nào xác định được năng lực của bạn vì tổ chức của bạn chưa tiến xa mấy trong vòng đời phát triển phần mềm.

Người lãnh đạo đánh giá sẽ không đánh giá tổ chức của bạn ở mức 3 bởi vì bạn sẽ không thoả mãn Miền qui trình kĩ nghệ sản phẩm Software Product Engineering Process Area (PA), điều yêu cầu rằng các hoạt động vòng đời đầy đủ được thực hiện. Nếu tổ chức của bạn mới chỉ hoàn thành một dự án trước nơi tổ đánh giá có thể nhìn vào các vật phẩm và kiểm điểm thực hành để xác định năng lực, thì bạn có thể thấy trước việc đạt tới mức 3. Tuy nhiên, tôi sẽ coi nó là tiền trưởng thành để xem xét tiến hành đánh giá vào lần này.

Hỏi: Tại sao chúng ta phải tuân theo trật tự các mức của CMMI? Hạn chế của việc làm mức 3 trước mức 2 là gì?

Đáp: Tại sao chúng ta không thể chạy được trước khi chúng ta có thể bước đi được? Phần lớn các tổ chức mức 1 đều có vấn đề với việc quản lí dự án. Nếu họ không thể giải quyết được vấn đề dự án thì đâu là cơ hội cho việc giải quyết vấn đề của tổ chức? Vấn đề chính ở đây là kỉ luật. Chẳng ích gì mà cố đưa vào chuẩn tổ chức nếu dự án không thể thực hiện được việc quản lí dự án cơ bản. Người ta phải không được bỏ sót việc học của tổ chức, thay đổi văn hoá yêu cầu thực hiện mức 2, và qui trình thể lệ hoá cần có tại chỗ như nền tảng cho tất cả các mức khác. Tuy nhiên, có vài hoạt động mức 3 mà tổ chức mức 1 có thể làm: a) Thiết lập Nhóm qui trình kĩ nghệ phần mềm – Software Engineering Process Group (SEPG), nếu nhóm này còn chưa tồn tại; và b) Bắt đầu tiến hành nhiều kiểm điểm ngang quyền để nhận diện và loại bỏ lỗi.

Hỏi: Giám định phần mềm là gì? Nó khác với kiểm điểm ngang quyền thế nào? Lỗi phần mềm là gì? Thầy tìm thấy nó ở đâu?

Đáp: Giám định phần mềm là phương pháp kiểm điểm sản phẩm phần mềm để trắc nghiệm rằng nó đáp ứng yêu cầu. Thường có người phát triển và vài người khác trong nhóm phần mềm tham gia vào đây như khách hàng, trong qui trình điều tra chính thức, để nhận diện và loại bỏ lỗi trong sản phẩm phần mềm.

Kiểm điểm ngang quyền là giám định phần mềm được tiến hành bởi một nhóm người bên trong tổ chức phần mềm – thường là nhóm ngang quyền.

Lỗi có thể được xác định như một thể nghiệm trong đó yêu cầu không được thoả mãn. Tất nhiên, người ta phải hiểu rằng yêu cầu là một cam kết đã được thoả thuận, không phải là việc đổi ý ở phút chót. Lỗi có thể được tìm thấy trong nhiều pha vòng đời phần mềm – yêu cầu, thiết kế, viết mã, kiểm thử, cài đặt, bảo trì, sản phẩm của nhà cung cấp, và/hoặc tài liệu.

Hỏi: Tại sao chúng ta cần phần mềm thương mại có sẵn – Commercial-Off-The-Shelf (COTS)? Việc ủng hộ và chống đối dùng COTS thay vì xây dựng phần mềm trong nhà là gì?

Đáp: Trong vài năm qua, có một quan niệm rằng chi phí phần mềm có thể được giảm đi đáng kể bằng việc tổ hợp phần mềm thương mại sẵn có (COTS). Đây là các cấu phần phần mềm có thể được cắm vào hệ phần mềm để cung cấp khả năng mà nếu không có thì phải được xây dựng. Hai đặc trưng nổi bật của phần mềm COTS là:

1) Mã nguồn không sẵn có cho người phát triển ứng dụng, và

2) Việc thay đổi COTS là không nằm dưới quyền điều khiển của người phát triển ứng dụng.

Lí do căn bản cho việc xây dựng hệ thống dựa trên COTS là ở chỗ chúng sẽ bao gồm ít thời gian phát triển hơn bởi việc tận dụng ưu thế của các sản phẩm đã có, đã được thị trường kiểm nghiệm, được nhà cung cấp hỗ trợ, do đó giảm chi phí phát triển hệ thống tổng thể. Tuy nhiên, bởi vì hai nhân tố xác định trên, có sự bù trừ trong việc dùng COTS:

1) Thời gian phát triển phần mềm có thể được rút bớt nhưng chi phí của việc tích hợp cấu phần phần mềm sẽ tăng lên.

2) Dùng phần mềm COTS có thể đem tới cùng nó nhiều rủi ro, hoàn toàn khác với phần mềm được phát triển tại nhà; trong trường hợp đó, bản kế hoạch giảm thiểu rủi ro cần được thực hiện.

Khi thực hiện COTS, tổ chức nên xác định chi phí đúng cho việc tích hợp, như cấp phép và quyền phân phối lại; tiền bản quyền, nỗ lực cần để hiểu phần mềm; thiết kế tiền tích hợp; đánh giá và ước lượng COTS; xác nhận hậu tích hợp về sự tuân thủ theo yêu cầu; miễn trừ trách nhiệm với các lỗi hay hỏng hóc gây ra bởi các cấu phần do nhà cung cấp trao; và chi phí phải chịu do không tương hợp với các hệ thống phần mềm hay phần cứng khác.

Bởi vì những rủi ro duy nhất này, việc dùng các cấu phần COTS trong phát triển hệ thống mới không phải là giải pháp phổ dụng để giảm chi phí và lịch biểu, trong khi vẫn duy trì chất lượng và chức năng mong muốn. Tuy nhiên, nếu những rủi ro này có thể được quản lí, việc dùng các cấu phần COTS có thể là giải pháp đúng, đưa ra cách tiếp cận chi phí-hiệu quả nhất, lịch biểu rút ngắn tới việc lắp ráp hệ thống phần mềm chính.

Tôi tin các cấu phần COTS là giải pháp đúng chỉ khi chúng nằm ở giao của ba yếu tố quyết định về tính khả thi (các ràng buộc kĩ thuật, kinh tế và chiến lược), và làm như thế theo cách tốt hơn nếu hệ thống mới được dự định xây dựng hoàn toàn từ phần mềm nguyên thuỷ. Chìa khoá để thành công trong việc dùng các cấu phần COTS là khả năng nhận diện liệu chúng có khớp với tình trạng mua sắm hiện thời về mặt kĩ thuật, kinh tế và chiến lược không. Về mặt kĩ thuật, chúng phải có khả năng cung cấp chức năng mong muốn ở mức tin cậy được yêu cầu. Về mặt kinh tế, chúng phải có khả năng được tổ hợp và duy trì trong hệ thống mới trong phạm vi ngân sách và lịch biểu sẵn có. Về mặt chiến lược, chúng phải đáp ứng nhu cầu của môi trường vận hành – điều bao hàm các xem xét về kĩ thuật, chính trị và pháp lí – bây giờ, và kho môi trường được mong đợi tiến hoá trong tương lai.

Hỏi: Làm sao thầy xác định qui trình phần mềm? Làm sao thầy xác định tổ chức? Tại sao thầy tiến hành đánh giá ở mức tổ chức mà không đánh giá ở mức dự án? Tại sao chúng ta cần có đánh giá CMMI? Chúng tôi biết cái gì làm việc và cái gì không làm việc trong tổ chức của mình, và chúng tôi tin rằng chúng tôi có thể làm việc đánh giá riêng của mình mà chẳng cần theo mô hình CMMI để đi tới mức trưởng thành?

Đáp: Qui trình phần mềm có thể được xác định là tập các hoạt động cùng làm việc với nhau để tạo ra sản phẩm đáp ứng các mong đợi về chi phí, lịch biểu, và chất lượng. Tổ chức có thể được xác định như tuyển tập các cá nhân, từng người đều đã cam kết với sứ mệnh của tổ chức, và từng người làm phần việc của mình trong qui trình phần mềm.

Tổ chức có thể có một hay nhiều dự án và có thể tiến hành đánh giá cho tổ chức với một dự án (giả định dự án là rất lớn). Tuy nhiên, trong Hệ thông tin, phần lớn các dự án đều nhỏ (ít người hơn, ngắn thời gian hơn); do đó, phạm vi của đánh giá nên tập trung vào năng lực của tổ chức.

Tôi đã thấy rằng phần lớn mọi người biết cái gì làm việc và cái gì không làm việc trong tổ chức riêng của họ, nhưng điều có thể mang tính chủ quan là đi tranh cãi giữa những người bên trong tổ chức đó. Ví dụ, hỏi vài trăm người một câu hỏi, và trông đợi đi tới một câu trả lời nhất trí! Bằng việc có một nhóm ‘bên ngoài” tiến hành đánh giá tình huống điều này có thể tránh được.

Khía cạnh quan trọng của đánh giá là ở chỗ chúng ta thu thập thích hợp các dữ liệu và sự kiện. Chúng ta dùng CMMI để hướng dẫn và tổ chức tuyển tập sự kiện này dựa trên quan sát chiều hướng của qui trình phần mềm, và điều mọi người làm để tạo ra phần mềm bằng việc tuân theo các qui trình này. Cố gắng thu thập những thông tin này mà không có mô hình, như CMMI, sẽ là khó bởi vì bạn có thể bỏ sót một số điều, hay có thể hội tụ vào điều sai.

Theo cảnh quan của tôi, CMMI là mô hình được thiết kế để hướng dẫn đánh giá. Khi tổ đánh giá báo cáo cho cấp quản lí rằng cái gì đó làm việc, cấp quản lí có thể nắm phát biểu này với sự tin tưởng, và tiếp tục dựa trên khuyến cáo của họ. Cấp quản lí cũng có thể giả định rằng tổ đã chứng minh tuyên bố này bên trong các điều kiện được lập ra cho đánh giá đó. Giống thế, nếu cái gì đó không làm việc tốt, tổ đánh giá phải chỉ ra điều này, và cấp quản lí có thể làm ra giả định rằng họ phải hành động để tránh rủi ro có thể gây tác động lên mục đích doanh nghiệp của họ.

Theo kinh nghiệm của tôi, hầu hết những người quản lí đều lấy hành động sửa chữa với đảm bảo rằng họ dựa trên nghiên cứu cẩn thận về vấn đề cần sự chú ý. Họ có thể tiến hành việc của mình, chính là quản lí rủi ro và đạt tới mục đích doanh nghiệp. Theo ý kiến của tôi, giá trị thực của đánh giá là nó cho tổ chức bức tranh đầu đủ về điều làm việc và điều không làm việc. Nó dứt khoát không đi tới con số mức CMMI vô nghĩa.

Hỏi: Chúng tôi là nhóm có 60 người nhưng 47 người trong số họ là lao động hợp đồng. Liệu có thể thực hiện CMMI khi đa số lực lượng lao động là lao động hợp đồng không? Họ có nghĩa vụ dùng CMMI không? Liệu có thể cho phép họ dùng phương pháp và công cụ riêng của họ không?

Đáp: CMMI là một khuôn khổ cho cải tiến qui trình, KHÔNG PHẢI là phương pháp luận có cấu trúc. Khuôn khổ CMMI có thể được áp dụng cho bất kì nhóm nào, lớn hay nhỏ, dù nó bao gồm lao động làm hợp đồng hay không. Nếu tổ chức bao gồm phần lớn là lao động hợp đồng, như trong trường hợp của bạn, tôi giả định rằng họ vẫn phải tuân theo những yêu cầu nào đó (đặc tả yêu cầu, Yêu cầu thay đổi v.v), và cần quản lí họ tương ứng. Họ vẫn cần xây dựng kế hoạch dự án với các ước lượng và lịch biểu. Và họ có thể phải theo dõi các hoạt động của mình so với kế hoạch và lịch biểu. Họ cũng cần chắc chắn về tính toàn vẹn của hệ thống, cũng như số hiệu phiên bản và phần mềm đưa ra, là dưới kiểm soát cấu hình.

Khái niệm then chốt là ở chỗ CMMI hội tụ vào CÁI GÌ được thực hiện – điều theo nghĩa thông thường nhất. LÀM SAO chúng thực hiện điều đó là tuỳ ở lực lượng lao động làm hợp đồng, bởi chỉ đạo từ cấp quản lí. Vì họ là lao động hợp đồng, tôi giả định họ đã có kĩ năng nào đó để làm việc của mình, cho nên BAO NHIÊU có thể không phải là quan trọng lắm. Tôi biết nhiều công ti dùng lao động hợp đồng cùng khắp và họ rất thành công khi áp dụng CMMI làm khuôn khổ. Thông thường, người lao động hợp đồng của họ tuân theo phương pháp luận riêng của họ để làm cho việc được thực hiện.

Hỏi: Dễ nhận diện tổ chức tương ứng theo năm mức như người lãnh đạo đánh giá, nhưng cái nhìn của người phát triển là gì?

Đáp: Được, đây là cái nhìn khác về năm mức của CMMI:

Mức 1:

Chúng ta không biết chúng ta ở đâu

Chúng ta không biết chúng ta đi đâu

Chúng ta có nhiều anh hùng

Nhưng phần lớn anh hùng không kéo dài, bởi vì họ không thể lặp lại hành động anh hùng của mình

Mức 2:

Chúng ta biết chúng ta ở đâu và chúng ta đang đi đâu

Chúng ta biết cách đi tới đó và chúng ta có thể lặp lại điều đó

Chúng ta biết biến thiên tồn tại và giải pháp chắp vá (ống khói) vẫn là qui tắc

Nhưng chúng ta cũng biết điều đó cuối cùng sụp đổ do thời gian

Mức 3:

Chúng ta biết chúng ta ở đâu và chúng ta đang đi đâu

Chúng ta nhất quán tuân theo tiến trình được lập kế hoạch tốt dựa trên dữ liệu lịch sử

Trên đường chúng ta chia sẻ những thực hành tốt nhất và chuẩn hoá các qui trình của mình

Chúng ta đo tiến bộ của mình, vẫn biết rằng chúng ta cần kiểm soát thống kê

Mức 4:

Chúng ta biết chúng ta ở đâu bằng sự kiện và chúng ta đã đi bao xa bằng dữ liệu

Chúng ta điều phối tiến bộ của mình một cách thống kê mọi tuần

Chúng ta biết chúng ta đóng góp bao nhiêu cho mục đích doanh nghiệp

Nhưng chúng ta còn chưa tối ưu qui trình của mình theo cách chúng ta nghĩ chúng ta phải vậy

Mức 5:

Chúng ta biết chúng ta ở đâu và chúng ta đi đâu dựa trên xu hướng công nghiệp

Chúng ta liên tục canh tân và hoàn thiện kĩ năng của mình

Chúng ta chấp nhận thay đổi khi chúng tới và công nghệ mới bằng cánh tay rộng mở

Và chúng ta tất cả đều có thời gian thoải mái trong cuộc hành trình không bao giờ chấm dứt!

English version

CMMI-30

Question: Should a person without software development experience be given the job of software project manager? Why and why not?

Answer: This is a very interesting question but it depends on the particular project and on personality characteristics of the software project manager. For some projects, a project manager with domain expertise is far more important than one with software development experience. For example, in the biotechnology industry, software project managers are often biologists or scientist. If they are good leaders, they can rely on their team’s software expertise to make technical decisions. The same could be found in business and marketing where a good business manager may be more important than one with software experience since he may be more customer-focused, as opposed to technology-focused. However, in a software industry, a software project manager must validate technical decisions and directions for the project. Without any software development experience, the manager may not be qualified to validate such decisions. As project manager needs to communicate to the development team. If he has no software experience, he will likely not be well versed in the programmer’s terminology and maybe unable to effectively direct the project. A software project manager with no experience is a bad judge of the effort required to implement features. If in addition, he does not keep track of effort, and, the developers in his team are not good, the project will almost certainly be late. A manager without experience may have difficulties in gaining the respect and trust of the developers in the team. This can negatively influence the team’s dynamics and the developer’s productivity.

Question: I believe what our company really need is hiring smart people instead of process improvement. Smart people can do a lot of things correctly and do not need to improve. What do you think?

Answer: Can you tell me where do I find smart people? Do they have the word “Smart” tattooed in their forehead? Based on my experiences, the best people for any company are not the smartest ones but the one with ability to learn. Technology today has a shelf life of about 5 years. That means obsolescence occurs at the rate of 20% a year. What you know today will become obsolete so fast that few years from now you may face uncertainty in securing a job. The only survivors are life long learners whom constant learning and changing will help them to thrive in this fast changing world. Learning does not mean you have to go back to school since people can learn from everyday activities such as the sharing of best practices, the analysis of data, lessons learned after project completion. Software organization offers a great deal of learning opportunities since it is changing on a daily basis. We are all very familiar with requirements change or technology change. I strongly believe that workplace provides the best learning environment. If we become complacent and not open for the on-going changes, such as process improvement activities, we will miss a significant opportunity to learn and the organization that fails to learn will not be successful in the long term. To success in the fast changing world, business must be able to cope with all changes by becoming a “learning organization” that always learn new things or else cease to exist. I believe the role of the SEPG is to create this learning organization where best practices are collected and shared. We must create a learning atmosphere, where learning goals are defined; skills and knowledge are clearly identified and linked to business strategy. Of course, the ability to learn still rest with the individual but a right environment and reward system can promote lifelong learning in all of us.

Question: My organization is planning an assessment this year. However, we are in a middle of a major re-organization. Our manager has left and we do not know who will be the new boss. Should we continue to plan our assessment?

Answer: No, absolutely NOT. Starting improvement during re-organization would be counterproductive because any improvement gains would be very difficult to sustain over a period of time. During this unstable period, having an assessment would be seen as non-value added since it may not truly reflect the organization capability maturity. Since your manager already left, you will need a new manager. Please wait for the new direction.

Question: What do you mean when you say that a SEPG member needs to be honest?

Answer: I can give you that a SEPG member NOT being honest when he or she only say thing they believe others wants to hear, ignore the hard, difficult issues, become too arrogant or hide behind technical jargon, and do not express their true feeling.

Question: Why do you emphasize too much on collect measurements? We have been collect data for years and it is always a waste of time since no one use the data anyway?

Answer: Before improve anything, you need to know the current performance or establish a baseline so you can track your progress. By collecting data about your software processes and products, you understand where improvement opportunities lie. For example, do you know how much your software cost last year per application? Which applications demand most of your time? How much time do you spend on testing? How accurately can you estimate future projects? What is the average number of defects your employees inject per thousand lines of code? Unless you collect these data and use the data to improve it, you never know how much you have improved. Of course, you do not collect data just for collecting sake but have to use them to improve things. Both collection and usage of data are essential in managing software products and processes.

Question: I want to be an SEPG member but do not know is there a career for this kind of work in the industry?

Answer: There is always a career for people who want to make the difference. An SEPG is a professional who want to improve the way organization build software products.

To start, you must be a highly technical people with a lot of software development experiences. You must have a thorough knowledge of the software life cycle, the domain and relevant technologies. Using your experiences, you can help the organization improve by sharing your thought on how things are done with others, collect best practices and measure progress. You always take an overall system view, exploring alternative approach, document processes and explain the key process areas. In this kind of work, you will eventually gain respect and earn a position of a software lead or a champion.

Question: No matter how hard we try to convince our customer about estimating based on historical data they always insist that we do thing their way. Any hope?

Answer: In this era of quickly and faster software development coupled with ever-changing requirements, the relationship between customer and developer is becoming very critical.

Somehow we continue to see ourselves either in the role of customer or developer but never member of a team with shared goals and vision. For years, we are taught to believe that customer and developer are separate entities, forced to work in a project. This hierarchy rules (Customer always right and win) will create friction and ultimately frustration from both sides.

It is about time that we (customer and developer) realize that there is either Win/Win or Lose/Lose but no Win/Lose situation here. A project manager primary role is making sure that project serves the needs of the business. If a software project fails, the business is not going to win either. In that spirit, customer and developer must strive to work together daily — even when there is no particular project to tackle. Every developer must have a sense of what makes our business successful, whether that means widgets sold, services provided, or code written. As business increasingly becomes more dependent on technology and technology dissolves into business process, the distinction between the two becomes increasingly irrelevant. I really believe working together to bridge this gap is the only hope for building better software.

Question: How do you make change happen when we spend most of our time document the “As is” process and “To be” Process so we can get to level 2?

Answer: It is common to think of change as a two-phase process: “As is” and “To be”. Many managers prefer to simply tell people what’s expected of them (To be) and leave the detail for them to work out. Such as: “I want to be at level 2 by certain date”.

Many people also believe if they document the “To be” process, change will naturally happen. They do not understand that the current state or “As is” is a comfortable environment; human being as a habitual creature will resist changes, any changes as much as possible.

Change is a journey to go from “As is” to “To be” and to make changes happen, managers need to create a sense of urgency, an uncomfortable for “Business as usual” atmosphere and a support process for changes to take place and allow people to adjust to new environment. Managers need to explain the rationale of why do we need to change, emphasize the cost of not changing, focus on the process of changing and be specific about what will happen if things do not work (Consequences and opportunities lost) and commit to make thing happens.

Question: Why bother with process since it only means a lot of documents, it inhibits creativity and wasting of effort.

Answer: I am sorry that you feel process means documentation only. A software process can also be:

a) Document all requirements after an agreement between user and developer.

b) Collect data such as estimates and actuals and use them for future estimates.

c) Follow a configuration procedure when change occurs or release product to users.

d) Conduct reviews of all requirements, designs, source code and test cases.

e) Create a quality assurance plan during project planning to review standard compliances, tracking defect, conduct reviews.

The notion that process limit creativity is based on idea that there is conflict between creativity and satisfaction of project business objectives. It is possible that certain over aggressive schedule may put project at risk but overall, business objectives can be in perfect harmony with creativity. Developers feel great when they are productive, managers feel great when the project complete within time and cost and these can be achieved by create a process that allow both side to work together with a shared goals and vision.

Question: It is obvious that process improvement is very important and is the right thing but why would we need a sponsor? Why not just do it?

Answer: The sponsor of process improvement will ensure that improvement activities receive adequate funding, time and support it needs for a successful effort. Improvement is a long journey that requires significant support to maintain the course. Without a visionary sponsor with significant “clout” it will not stand a chance.

Question: We are a new company with only one large project. We just start to work on requirement phase at this time but would like to have an assessment done and hope to achieve at least maturity level 3. How do we proceed with this, and is it possible to make level 3?

Answer: Why would you want to have an assessment? Is it for improvement purposes or just to satisfy a curious notion regarding a maturity level? Why is level 3 important to you? Process improvement is an investment that requires management commitment and hard work. An assessment is only the beginning, to establish a baseline for improvement, not the end of an event to find out about a level. Have you considered the consequence of an assessment? What if your organization is assessed at level 1 and not level 3? Would you and your people be ready to accept it? What would be the next step? Would you continue the improvement effort? Would your management still support the improvement activities? From the technical point of view, it is impossible to determine your capability since your organization has not gotten very far in the software development life cycle. A Lead assessor will not assess your organization at level 3 because you will not satisfy the Software Product Engineering Process Area (PA), which requires that full life cycle activities are performed. If your organization had just completed a previous project where an assessment team could look at artifacts and review practices to determine capability, you could then anticipate achieving level 3. However, I would consider it pre-mature to consider conducting an assessment at this time.

Question: Why do we have to follow the order of CMMI levels? What is the drawback of doing level 3 before level 2?

Answer: Why can’t we run before we can walk? Most Level 1 organizations have problems with managing projects. If they can’t solve project problems then what is the chance of solving organization’s problems? The primary issue here is discipline. There’s no point trying to put in place an organization standard if the projects cannot execute basic project management. One should not overlook organizational learning, cultural change required to implement Level 2, and the institutionalization process needed to be in place to serve as the foundation for all other levels. However, there are a few level 3 activities a level 1 organization can do: a) Establish a Software Engineering Process Group (SEPG), if one doesn’t already exist; and b) Start to conduct more peer reviews to identify and remove defects.

Question: What is software inspection? How does it differ from a Peer Review? What is a software defect? Where do you find it?

Answer: Software inspection is a method of reviewing software product to verify that it meets requirements. It usually engages the developers and a few others within the software group or outside the group such as customer, in a formal investigation process, to identify and remove defects in the software product.

A Peer Review is a software inspection conducted by a group of people within the software organization – usually a peer group.

A defect can be defined as an instance in which a requirement is not satisfied. Of course, it must be understood that a requirement is an agreed-upon commitment, not a last minute change of mind. A defect can be found in any of the software life cycle phases – Requirements, Design, Code, Test, Installation, Maintenance, Vendor products, and/or documentation.

Question: Why do we need Commercial-Off-The-Shelf (COTS)? What are the pros and cons of using COTS instead of building software in house?

Answer: In the past few years, there is a notion that software costs can be significantly reduced by incorporating Commercial-Off-The-Shelf (COTS) software. These are software components that can be plugged into a software system to provide capability that would otherwise have to be built. The two distinguishing characteristics of COTS software are:

1) Source code is not available to the application developer, and

2) The change of COTS is not under the control of the application developer.

The rationale for building COTS-based systems is that they will involve less development time by taking advantage of existing, market-proven, vendor- supported products, thereby reducing overall system development costs. However, because of the two defining characteristics above, there is trade-off in using the COTS:

1) Software development time can be reduced but the cost of software component integration work will increase.

2) Using COTS software can bring with it several risks, quite different from software which is developed in-house; in which case, a risk mitigation plan must be implemented.

When implementing COTS, an organization should determine the true cost of integrating, such as: licensing and redistribution rights; royalties; efforts needed to understand COTS software; pre-integration design; COTS assessment and evaluation; post-integration certification of compliance with requirements; indemnification against faults or damage caused by vendor-supplied components; and costs incurred due to incompatibilities with other software or hardware systems.

Because of these unique risks, using COTS components in the development of new systems is not the universal solution to reducing cost and schedule, while maintaining desired quality and functionality. However, if these risks can be managed, using COTS components can be the right solution, offering the most cost-effective, reduced-schedule approach to assembling major software systems.

I believe COTS components are the right solution only when they lie at the intersection of the three determinants of feasibility (technical, economic, and strategic constraints), and do so in a way better than if a new system were to be constructed entirely out of original software. The key to success in using COTS components is being able to identify whether they fit the current procurement situation ¾ technically, economically, and strategically. Technically, they have to be able to supply the desired functionality at the required level of reliability. Economically, they have to be able to be incorporated and maintained in the new system within the available budget and schedule. Strategically, they have to meet the needs of the operating environment—which includes technical, political, and legal considerations—now, and as that environment is expected to evolve in the future.

Question: How do you define software process? How do you define an organization? Why do you conduct assessments at the organization level and not at the project level? Why do we need to have the CMMI assessment? We know what works and what does not work in our organization, and we believe that we can do our own assessment without following the CMMI model to come up with a maturity level?

Answer: Software process can be defined as a set of activities that work together to produce a product that meets cost, schedule, and quality expectations. The organization can be defined as a collection of individuals, each committed to the mission of the organization, and each doing their part in the software process.

An organization may have one or more projects and it is possible to conduct an assessment for the one-project organization (assuming the project is very large). However, in Information Systems, most projects are small (fewer people, shorter time); therefore, the scope of the assessment is focused on the organization capability.

I have found that most people know what works and what does not in their own organization, but it could be subjected to a debate between people within that organization. As example, ask a few hundred people a question, and expect to come up with one unanimous answer! By having an “outside” group conduct the assessment this situation can be avoided.

The important aspect of an assessment is that we adequately collect facts and data. We use the CMMI to guide and organize this collection of facts based on direct observations of the software processes, and what people do to produce software by following these processes. Trying to collect these in formation without a model, such as the CMMI, would be difficult since you may overlook some things, or may focus on the wrong things.

From my perspective, the CMMI is a model designed to guide the assessment. When an assessment team reports to management that something works, management can take this statement with confidence, and continue to rely upon their recommendations. Management can assume that the team has substantiated this claim within the conditions set forth for the assessment. Likewise, if something is not working well, the assessment team should point this out, and management can make an assumption that they have to act to avoid the risk that could impact their business goals.

Based on my experience, most managers do take corrective action with assurance that they are relying on a careful investigation of the issues that need attention. They can get on with their job, which is to manage risks and achieve business goals. In my opinion, the true value of an assessment is it gives an organization a complete picture of what works and what does not. It is definitely not to come up with just a meaningless CMMI level number.

Question: We are a group of 60 people but 47 of them are contract labor. Is it possible to implement CMMI when the majority of the workforce is contract labor? Would they have an obligation to use CMMI? Is it possible to allow them to use their own method and tools?

Answer: The CMMI is a framework for process improvement, NOT a structured methodology. The CMMI framework can be applied to any group, big or small, whether it consists of contract labor or not. If the organization consists of mostly contract labor, as in your case, I assume that they still have to follow certain requirements (Requirements specification, Change Requests, etc), and need to manage them accordingly. They still need to develop a project plan with estimates and schedules. And they may have to track their activities against the plan and schedule. They also need to make sure the integrity of the system, as well as the version number of release software, is under configuration control.

The key concept is that CMMI focuses on WHAT is to be done—which is mostly common sense. HOW they do that is up to the contract labor force, by direction from the management. Since they are contract labor, I assume they already have certain skills to do their job, so the HOW may not be as important. I know many companies that use contract labor extensively and they are very successfully applying CMMI as the framework. Often, their contract laborers follow their own methodology to get the job done.

Question: It is easy to identify organization according to five levels as a Lead appraiser but what is the developer’s view?

Answer: OK, here is another view of the five levels of CMMI:

Level 1:

We do not know where we are

We do not know where we go

We have a lot of heroes

But most do not last long, because they cannot repeat their heroic act

Level 2:

We know where we are and where we are going

We know how to get there and we can repeat it

We know variations exist and the stovepipe solution is still the rule

But we also know it will eventually break down in due time