Hỏi: Tại sao chúng ta cần cải tiến phần mềm? Thầy có dữ liệu nào chỉ ra rằng phần mềm cần cải tiến không?

Đáp: Tôi rất mừng là bạn đã hỏi. Có hàng trăm nhà nghiên cứu trong hai mươi năm qua đề cập tới tình trạng của việc hàng nghề phần mềm, phần lớn trong họ đều chỉ ra rằng công nghiệp phần mềm thực sự cần cải tiến. Năm 2005, tôi đã tham gia vào làm bảng so sánh công nghiệp phần mềm của trên 4000 dự án phần mềm. Chúng tôi đã tới thăm 186 công ti ở Mĩ, châu Âu và châu Á để thu thập dữ liệu và thấy rằng:

Dự án phát triển phần mềm trung bình vượt quá ngân sách được lập kế hoạch của nó đến 90% và quá lịch của nó tới 120%

33% số mọi dự án đều quá ngân sách

53% dự án sẽ tốn 189% so với ước lượng ban đầu của họ

Chỉ 16.2% dự án được hoàn thành đúng thời gian và trong ngân sách

Thời gian trung bình phải làm quá thêm là 222% thời gian ước lượng ban đầu

Trong các công ti lớn, chỉ 9% số dự án là đúng thời gian và đúng ngân sách

Hầu hết các dự án thất bại đều mang định mệnh đó từ lúc bắt đầu do lập kế hoạch kém.

Dựa trên những dữ liệu mới nhất này, tôi kết luận rằng công nghiệp phần mềm thực sự cần cải thiện thực hành của nó thật nhanh chóng.

 

Hỏi: Tôi ngạc nhiên khi thấy sau nhiều năm mọi người vẫn vật lộn với vấn đề cải tiến qui trình phần mềm. Tôi không nghĩ nó khó hơn là học công cụ mới hay công nghệ mới.

Đáp: Cải tiến qui trình phần mềm không dễ như bạn tưởng. Bất kì ai tin điều khác đều hoặc chưa bao giờ thử nó hoặc chưa bao giờ làm việc với bất kì cải tiến kéo dài nào. Học qui trình mới hay công cụ mới chỉ là bắt đầu, có nhiều khía cạnh con người cần phải làm việc kĩ khi bạn định thay đổi cách mọi người hành xử trong tổ chức.

Qui trình mới hay cải tiến đều phải được xác định, được làm tài liệu, được sử dụng, được đo về hiệu lực và hiệu năng, và liên tục được cải tiến dựa trên dữ liệu được thu thập. Cải tiến xảy ra trong tổ chức có nghĩa là mọi người trong tổ chức đó, mọi dự án đều phải chấp nhận những thay đổi. Để thay đổi xảy ra, kết cấu nền phải có tại chỗ, điều này bao hàm nhóm chỉ đạo quản lí đưa ra viễn kiến, mục đích, và chiều hướng cho tổ chức, Nhóm qui trình kĩ nghệ phần mềm – Software Engineering Process Group (SEPG) thực hiện trao đổi, tạo điều kiện, thu thập dữ liệu và chia sẻ các hoạt động cải tiến bên trong tổ chức, và Tổ hành động qui trình – Process Action Teams (PAT), hội tụ vào làm việc trên các nhiệm vụ cải tiến, dựa trên các kết quả đánh giá. Mọi cải tiến đều phải được phối hợp, tạo điều kiện và chúng phải kéo dài trong một thời gian lâu.

Không có loại kết cấu nền này, khó mà làm cho cải tiến được kéo dài hay được thể lệ hoá đầu đủ cho bất kì qui trình hay công nghệ nào.

 

Hỏi: Làm sao thầy quản lí được những người hành nghề phần mềm một cách hiệu quả khi công nghệ và tổ chức đang thay đổi nhanh chóng?

Đáp: Nhiều người quản lí tin rằng “quản lí” nghĩa là kiểm soát.  Họ nghĩ rằng nếu họ có thể giữ cho người hành nghề phần mềm thực hiện theo cách nào đó vào những lúc nào đó, họ thành công.

Nhưng kết quả không phải bao giờ cũng là điều họ dự đoán bởi vì tổ chức ngày nay cực kì phức tạp.  Tổ chức bao gồm đa dạng con người tương tác và ảnh hưởng lẫn nhau, đem tới những hành vi mới cho tổ chức như một toàn thể.  Và khi môi trường thay đổi, hành vi của con người của nó cũng thay đổi theo – thay đổi để thích ứng với thay đổi mới. Để thành công, người quản lí cần nhận ra rằng họ là một phần của phức hợp này, không đứng xa khỏi nó. Họ là liên thuộc và phụ thuộc lẫn nhau để hoàn thành các mục đích và mục tiêu. Cho nên ảo tưởng về kiểm soát quản lí toàn bộ không còn hợp thức nữa.  Trong thời đại thay đổi nhanh chóng này, người quản lí thành công phải:

1)   Đưa ra viễn kiến, chiều hướng rõ ràng, và giá trị mạnh, nhưng hiểu rằng thay đổi cần thời gian.

2)   Truy cập được tới các nhân viên và chăm sóc họ. Biết họ, hỏi điều họ cần và xây dựng sự tin cậy.

3)   Hiểu tổ chức như một toàn thể bằng việc phát triển thông cảm với các nhân viên và học cách lắng nghe mối quan tâm của họ. Cách bạn lắng nghe có thể thay đổi thái độ của mọi người và bao giờ cũng nhớ đáp ứng với điều bạn nghe thấy.

Tôi biết đây là điều khó bởi vì mọi người quản lí đều rất bận rộn với nhiều điều phải làm nhưng bạn phải hiểu rằng chính người nhân viên mới làm công việc của bạn. Chúng ta đang sống trong thời đại thay đổi nhanh và cách tốt nhất để thu hoạch được ích lợi của thay đổi nhanh chóng trong tổ chức kinh doanh phức tạp ngày nay là để cho người giỏi nhất làm việc cho bạn và ở cùng bạn. Không ai có thể tự mình làm mọi việc nhưng mọi điều chúng ta làm đều phụ thuộc vào lẫn nhau và việc của người quản lí càng ngày càng trở nên phức tạp hơn chỉ người giỏi nhất mới thành công.

 

Hỏi: Sao ngăn ngừa khiếm khuyết lại có ở CMMI mức trưởng thành 5 thay vì mức 2?

Đáp: Ngăn ngừa khiếm khuyết là quá trình nắm bắt và nghiên cứu lỗi và xu hướng của nó để cho tổ chức có thể ngăn ngừa chúng không xảy ra lặp lại.

Theo cảnh quan CMMI, ngăn ngừa khiếm khuyết yêu cầu tổ chức phải có qui trình chuẩn để thu thập, phân tích dữ liệu khiếm khuyết để nhận diện nguyên nhân gốc rễ, kiểm điểm sự thường xuyên xuất hiện và tạo ra qui trình để khử bỏ khiếm khuyết và giáo dục các kĩ sư về những sai lầm thông thường này.

Về căn bản ở mức 2, tổ chức bị tràn ngập bởi sức ép lịch biểu và ưu tiên hàng đầu là quản lí các dự án cho đúng lịch. Do đó, rất khó có thời gian và tài nguyên để nhận diện khiếm khuyết. Phần lớn các hoạt động loại bỏ khiếm khuyết đều được tiến hành bất kì khi nào thời gian cho phép.

Ở mức 3, tổ chức có thể kiểm soát được lịch biểu dự án tới mức độ nào đó và ưu tiên là để áp dụng “thực hành tốt nhất” cho mọi dự án để đạt tới nhất quán toàn thể. Tại mức trưởng thành này, tổ chức có thể hội tụ nhiều hơn vào kiểm điểm chính thức và giám định để nhận diện và loại bỏ khiếm khuyết.

Ở mức 4, tổ chức rất ổn định do việc quản lí dự án vững chãi và chuẩn hoá qui trình. Ưu tiên then chốt là hội tụ vào kiểm soát qui trình thống kê dựa trên nhu cầu doanh nghiệp. Đây là nơi việc phân tích nguyên nhân gốc rễ xảy ra và hoạt động ngăn ngừa khiếm khuyết bắt đầu.

Ở mức 5, do việc phân tích dữ liệu vững chắc và việc kiểm soát qui trình thống kê chính thức, tổ chức có thể khử bỏ được hầu hết các qui trình phi chính qui và ngăn ngừa khiếm khuyết xảy ra.

 

Hỏi: Tại sao chúng ta phải tạo ra kế hoạch dự án mới mỗi lúc? Sao chúng ta không dùng lại kế hoạch dự án trước để tiết kiệm thời gian và tiền bạc?

Đáp: Tôi biết nhiều người dùng lại kế hoạch dự án của họ. Điều này có tác dụng khi dự án mới giống như dự án cũ. Khi mọi sự khác đi, việc dùng lại kế hoạch hay khuôn mẫu cũ có thể tạo ra vấn đề.

Mọi dự án đều phải đề cập tới nhu cầu đặc thù của dự án đặc thù và cho dù có thể có sự tương tự nào đó, từng dự án vẫn duy nhất. Người quản lí dự án phải cẩn thận khi lập kế hoạch dự án mới và áp dụng tư duy phê phán cho từng bước. Không khuôn mẫu nào có thể đề cập tới mọi nhu cầu cũng như mọi yêu cầu.

 

Hỏi: Qui trình phần mềm là gì? Định nghĩa của thầy về tổ chức là gì? Chúng ta có biết cái gì có tác dụng và không tác dụng trong tổ chức của mình không? Sao chúng ta cần đánh giá?

Đáp: Qui trình phần mềm là tập các hoạt động cùng làm việc với nhau để tạo ra sản phẩm phần mềm đáp ứng các mong đợi về chi phí, lịch biểu, và chất lượng.

Tổ chức là tập hợp các cá nhân làm việc cùng nhau, từng người đều cam kết với sứ mệnh của tổ chức, và làm phần việc của mình để hỗ trợ cho nó.

Phần lớn mọi người đều biết cái gì có tác dụng và cái gì không có tác dụng trong tổ chức của mình nhưng họ có thể không đồng ý với nhau. Khía cạnh then chốt của việc đánh giá là ở chỗ tổ đánh giá thu thập những góc nhìn này thật chi tiết và dùng khuôn khổ như CMMI để hướng dẫn và tổ chức thông tin này. Cố gắng thu thập thông tin mà không có mô hình như CMMI sẽ là rất khó vì tổ có thể bỏ sót cái gì đó, hay hội tụ vào điều sai.

CMMI là mô hình được xác định tốt và được chấp nhận dùng để hướng dẫn việc đánh giá và các hoạt động cải tiến. Khi tổ này cung cấp các phát kiến đánh giá, cấp quản lí có thể lấy thông tin này với sự tin cậy và an toàn giả định rằng tổ đã chứng minh lời tuyên bố này với các điều kiện được đặt ra cho việc đánh giá.

 

Hỏi: Làm sao phải mất nhiều năm để lên tới một mức CMMI? Mức khó khăn nhất cần vượt qua là gì?

Đáp: Từng mức trưởng thành đều đại diện cho một tập các hành vi mà mọi người thực hiện trong tổ chức. Đi lên một mức yêu cầu thay đổi trong hành vi và thay đổi không bao giờ là dễ dàng.

Nếu bạn bắt đầu từ mức 1 thì bạn sẽ thấy mức 2 là rất khó vì bạn phải bắt đầu thay đổi và vượt qua sự chống cự lại thay đổi. Theo quan điểm kĩ thuật, mức 2 không khó nhưng nó là nhận biết, giáo dục, trao đổi và vượt qua sự kháng cự thay đổi cần có thời gian.

Nếu bạn bắt đầu từ mức 2 thì bạn có thể thấy mức 3 là khó bởi vì bạn không còn trong “mô thức dự án” mà chuyển vào “mô thức toàn tổ chức.” Điều này yêu cầu nhiều chia sẻ về các thực hành tốt nhất và xây dựng tổ, đó cũng là thay đổi rất lớn.

Theo kinh nghiệm riêng của tôi, mức 4 có lẽ là thách thức lớn nhất. Chừng nào tổ chức của bạn còn chưa có độ đo thực tốt, nơi sự kiện và dữ liệu tồn tại, việc dùng kiểm soát thống kê là khó bao quát được vì nó yêu cầu nhiều kĩ năng và tri thức hơn người trung bình có. Khía cạnh then chốt của mức 4 là sử dụng dữ liệu hiện có thành thông tin hữu dụng cho cấp quản lí để ra quyết định và điều chỉnh qui trình chuẩn hiện có.

Mức 5 là tương đối trực tiếp và về căn bản là sự mở rộng của điều tổ chức đã làm trên cuộc hành trình từ 1 tới 4.

 

Hỏi: Xin thầy mô tả các phương pháp PSP và TSP và nhận diện cách chúng khớp với hoạt động cải tiến qui trình?

Đáp: Qui trình phần mềm cá nhân – Personal Software Process (PSP) là phương pháp đem kỉ luật tới cá nhân người kĩ sư phần mềm.

PSP bao quát hầu hết các nhiệm vụ phát triển phần mềm bao gồm xác định yêu cầu, thiết kế kiến trúc, phát triển mô đun, và sản xuất tài liệu. Bởi vì nó ở mức cá nhân, nó được thiết kế theo cách tiếp cận dưới lên, cải tiến kĩ năng của người kĩ sư ở mỗi lúc.

Phương pháp PSP cho phép người kĩ sư có cơ hội nhìn vào qui trình riêng của mình, kiểm điểm hiệu năng riêng của họ, nhận diện điểm yếu điểm mạnh của họ theo định lượng, và rút ra kết luận về điều họ cần cải tiến. Nó là qui trình rất chặt chẽ tương tự như phấn đấu riêng của vận động viên để giành danh hiệu vô địch.

Qui trình phần mềm tổ – Team Software Process (TSP) là phương pháp giúp đưa người kĩ sư đã được đào tạo về PSP vào tổ tự quản, hiệu năng cao. TSP cho phép các thành viên tổ quản lí công việc của họ một cách hiệu quả bằng việc định nghĩa rõ ràng quyền người chủ, vai trò và trách nhiệm. Các thành viên theo dõi dấu vết công việc, tiến độ và hiệu năng của mình so với lịch biểu và mục đích của tổ.

Qui trình TSP là hoạt động lập kế hoạch dựa trên tổ (còn được gọi là khai trương -launches) để đưa dự án chi tiết vào vị trí. Thành viên tổ nhận diện các nhiệm vụ, sự phụ thuộc và vấn đề trong môi trường cộng tác. Do nỗ lực của tổ, lỗi từ nhiều nhiệm vụ không có quan hệ hay từ các ước lượng có khuynh hướng cắt bỏ đi. Các kế hoạch về căn bản có trung bình hai cột mốc một tuần cho thành viên tổ. Lược đồ giá trị thu được được dùng để dõi vết dự án, tức là khi nào nhiệm vụ hoàn thành, có ghi công cho giá trị của nhiệm vụ. Không có ghi công bộ phận cho nhiệm vụ chưa hoàn thành. Cuộc họp trạng thái hàng tuần cung cấp cơ chế cho việc dõi vết và báo cáo tiến độ.  Từng thành viên tổ đều dõi vết và trình bày trạng thái của họ cho tuần đó. Qui trình TSP hướng tới nhiệm vụ cao đảm bảo độ chính xác của qui trình.  Các xu hướng bày tỏ rất nhanh chóng và may rủi được nhận diện và ước lượng. Những sửa chữa sớm sủa có cơ hội thành công tốt hơn nhiều so với sửa chữa muộn về sau, cho nên nói chung có nhiều khả năng tránh được những vấn đề chính nhiều hơn.  Việc dõi vết trung thành cao cũng tạo khả năng cho việc cân bằng tải linh động và quản lí đường găng, nơi công việc liên tục bị dịch chuyển quanh tổ để làm tối ưu việc sử dụng tài nguyên, để bám sát theo ngày tháng đã lên kế hoạch. Ý tưởng then chốt là qui trình cam kết, vì tổ xây dựng kế hoạch; họ sở hữu nó và sẽ dùng nó. Nó là qui trình có kỉ luật rất chặt chẽ tương tự như kế hoạch thi đấu của tổ thể thao chuyên nghiệp, được huấn luyện viên và các vận động viên thiết kế ra.

Có những ý kiến khác nhau liên quan tới việc dùng PSP/TSP. Một số người tin rằng PSP/TSP có thể được dùng ở bất kì mức CMMI nào vì nó hội tụ vào cá nhân. Tuy nhiên, dựa trên kinh nghiệm riêng của tôi, phương pháp này được dùng tốt nhất cho CMMI mức 4 hay 5 do bản chất bất ổn của các mức thấp hơn khác. PSP/TSP là qui trình rất có kỉ luật tự giác, yêu cầu sự hỗ trợ lớn từ cấp quản lí. Ở mức thấp hơn, như mức 1 hay 2, sức ép lịch biểu dứt khoát sẽ huỷ hoại bất kì nỗ lực nào dùng phương pháp này. Không có qui trình chuẩn tại chỗ (mức 3) việc dùng PSP/TSP sẽ không giữ được vì nó sẽ bị coi là “chỉ là hương vị khác của tháng đó”. Cho tới khi văn hoá thực sự thay đổi và tổ chức bắt đầu hội tụ vào sự kiện và dữ liệu (mức 4), PSP/TSP sẽ nổi lên như “phương pháp được ưa chuộng” và sẽ thay đổi đáng kể cách thức chúng ta thực hành kĩ nghệ phần mềm.

 

Hỏi: Dường như là khi tổ chức không cải tiến, SEPG bao giờ cũng chịu trách nhiệm. Tôi rất thất vọng với tiến bộ cải tiến của chúng tôi, chúng tôi đã làm mọi thứ chúng tôi có thể làm mà chẳng cái gì xảy ra cả. Thầy có gợi ý gì không?

Đáp: Khi cải tiến thất bại, mọi người nên chia sẻ phần trách cứ. Dễ dàng chỉ tay vào SEPG bởi vì chính việc của họ là cải tiến qui trình nhưng tôi tin cấp quản lí nên chia sẻ hầu hết gánh nặng này bởi vì chính chỉ đạo và lãnh đạo của họ mới làm mọi sự xảy ra. Chúng ta đừng xoáy vào lỗi của ai mà nên nhìn vào cách thức cải tiến được thực hiện trong tổ chức của bạn.

Tôi chắc chắn các thành viên SEPG của bạn đã làm mọi thứ họ biết nhưng họ cần kiểm điểm cách tiếp cận của họ và hỏi tại sao cải tiến dường như không xảy ra. Tôi muốn gợi ý vài câu hỏi sau:

1)   SEPG có tích cực làm việc với các dự án và không dành nhiều thời gian vào các cuộc họp riêng của họ?

2)   SEPG có trao đổi về qui trình mới cho mọi người trong tổ chức của bạn không?

3)   SEPG có động viên mọi người trong tổ chức tham gia vào phát triển qui trình mới không?

4)   SEPG dành bao nhiêu thời gian để biện luận cho thực hành mới hay hỗ trợ mọi người chấp nhận thực hành mới này?

5)   SEPG có dành đủ thời gian cho việc thể lệ hoá không?

6)   Cấp quản lí có kiểm điểm trạng thái cải tiến trên cơ sở đều đặn không?

7)   Cấp quản lí có động viên mọi người tuân theo qui trình chuẩn không?

8)   Tổ chức có khuyến khích mọi người thay đổi không?

9)   Tổ chức có thừa nhận những người đã chấp nhận trước không?

10)  Liệu có khả năng rằng tổ chức bị xô vào làm việc ở mức 3 thay vì thể lệ hoá các qui trình mức 2?

11)  Bạn có xem xét liên hệ với nhà tư vấn ngoài để có hỗ trợ thêm không?

Tôi mạnh mẽ thôi thúc mọi người SEPG kiểm điểm cách tiếp cận của họ trên cơ sở hàng quí, xác định cái gì có tác dụng và cái gì không có tác dụng và lấy hành động sửa chữa. SEPG cần chia sẻ kết quả này với phần còn lại của tổ chức và hỏi xin gợi ý. Theo kinh nghiệm của tôi, nhiều thất bại trong cải tiến qui trình là do SEPG không yêu cầu giúp đỡ cho tới khi sự việc quá trễ.

 

Hỏi: Tại sao chúng ta cần dữ liệu đo để đáp ứng CMMI mức 3?

Đáp: Mục đích của thu thập cách đo là cho người quản lí dữ liệu họ cần để ra quyết định về dự án và tổ chức, đánh giá tiến độ so với mục đích và mục tiêu đã xác định, và có hành động sửa chữa cần thiết để cho kết quả mong muốn. Không có những việc đo này, người quản lí không thể ra quyết định được thông tin đầy đủ và không thể quản lí tổ chức của mình một cách có hiệu quả.

Cũng giống như khi lái xe bạn cần nhìn và các dụng cụ đo nào đó như tốc độ, xăng, đồng hồ vận tốc v.v. Người quản lí cần thông tin để quản lí nhóm của mình và thông tin phải được thu thập bất kể mức CMMI nào.

 

Hỏi: Là người lập trình, tôi bao giờ cũng tin rằng thành thạo lập trình sẽ cho tôi khả năng giữ việc một thời gian dài. Tuy nhiên, tôi rất thất vọng rằng nhiều công ti đang khoán ngoài ra nước ngoài, dường như là tương lai của phần mềm rất ảm đạm. Xin thầy bình luận.

Đáp: Toàn cầu hoá xảy ra và nhiều việc lập trình có thể đi sang đâu đó khác nhưng đây là xu hướng trong công nghiệp. Phần lớn các công ti đều vận hành theo lợi nhuận và nếu họ không giảm được giá của mình bằng cách thúc bẩy dùng công nhân lương thấp ở đâu đó khác và đối thủ cạnh tranh của họ lại làm thế, họ không thể cạnh tranh được trong thị trường mở. Vài năm trước đây, nhiều việc xưởng máy đã ra đi và mọi người đều tức giận nhưng nhiều người vượt qua được điều đó và tìm ra nghề mới trong công nghệ nhưng bây giờ đến lượt phần mềm đi đâu đó khác và tôi chắc một số người sẽ tức giận.

Tuy nhiên, không phải tất cả các nghề phần mềm sẽ được khoán ngoài. Tôi tin trong nhiều cấp quản lí việc sẽ vẫn còn như với vài vị trí then chốt kiểu kĩ sư hệ thống, người phân tích doanh nghiệp, quản trị mạng, thiết kế giao diện người dùng, quản lí dự án, quản lí yêu cầu, kiến trúc phần mềm, và kĩ sư tích hợp v.v.

Chừng nào bạn còn chưa muốn học các kĩ năng mới mà vẫn ưa thích lập trình thì tương lai có thể ảm đạm. Tôi có mong đợi rằng xu hướng toàn cầu hoá sẽ tiếp tục trong mười năm tới với nhiều việc lập trình được dịch chuyển đi đâu đó khác và người lập trình sẽ cạnh tranh với ít việc làm hơn.

 

Hỏi: Thư viện tài sản qui trình, mục đích của nó và mối quan hệ của nó trong CMMI là gì?

Đáp: Câu trả lời đơn giản là ở chỗ tại các dự án CMMI mức 2 có thể dùng bất kì qui trình được làm tài liệu nào mà họ muốn, trong khi ở mức 3 họ phải tuân theo các thực hành tốt nhất (Qui trình, phương pháp, công cụ) từ các dự án trước đây đã được nhận diện và lưu giữ trong thư viện tài sản qui trình để các dự án khác dùng lại.

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 (OSSP) và đặt ra giai đoạn cho thu thập cách đo về việc dùng các tài sản đó. Điều này trở thành chủ đề cho CMMI mức 3 rằng tổ chức không còn là kho dự án mà dịch chuyển sang tổ chức học tập và có qui trình được quản lí hơn. Cách đo dựa trên việc dùng cùng tài sản cơ sở cho phép việc so sánh cùng kiểu của kết quả của các dự án khác nhau qua thời gian, điều tạo nên cơ sở của khả năng vận hành ở mức trưởng thành 4.

Ở mức 4 các dự án, được quản lí theo tập các mục đích dùng các kĩ thuật kiểm soát qui trình thống kê và dữ liệu được thu thập trong số các dự án, có thể được dùng để nhận diện tài sản nào đã từng là nguyên nhân của các biến thiên. Tài sản gây ra biến thiên là ứng cử viên cho cải tiến ở mức 5 trong miền qui trình then chốt Quản lí thay đổi qui trình công nghệ, nơi công cụ, phương pháp và qui trình được nâng cấp để giảm biến thiên.

 

Hỏi: CMMI phần mềm có hội tụ chỉ vào người hành nghề phần mềm không? Ai khác sẽ bị ảnh hưởng bởi nó?

Đáp: Không, CMMI phần mềm không chỉ dành cho người hành nghề phần mềm. CMMI phần mềm hội tụ vào thay đổi cách việc phát triển phần mềm và cách phần mềm được quản lí như dự án (mức 2), như sản phẩm (mức 3), như sản phẩm và dịch vụ doanh nghiệp (mức 4) và như kinh doanh then chốt của công ti (mức 5). Để cải tiến xảy ra mọi người đều phải tham gia và cam kết làm cho nó xảy ra.

 

Hỏi: Tôi bị lẫn lộn giữa vai trò của tiên phong cải tiến qui trình và tác nhân thay đổi. Là thành viên SEPG tôi phải là tiên phong hay tác nhân thay đổi?

Đáp: Theo định nghĩa, tiên phong là người khởi đầu, thúc đẩy và duy trì đà cải tiến.

Bắt đầu một sáng kiến cải tiến trong bất kì công ti nào đều yêu cầu nhiều nỗ lực, kĩ năng và tài năng. Tiên phong phải có đề xuất đúng và phát sinh nhiều nhiệt tình hướng tới cải tiến để thu được sự hỗ trợ từ quản lí cấp cao. Ngay cả khi chiều hướng cải tiến đang xảy ra, tiên phong phải khởi xướng viễn kiến và mục tiêu một cách rõ ràng để thuyết phục quản lí cấp trung, giải thích và thu được hỗ trợ từ những người hành nghề để làm cho điều đó vận hành. Việc khởi xướng này là quá trình tiếp diễn để duy trì đà cải tiến. Tiên phong phải bảo vệ sáng kiến này chống lại sự nghi ngại, tiêu cực và kháng cự lại hoạt động thay đổi và điều này yêu cầu cam kết và kiên nhẫn rất mạnh.

Theo định nghĩa, tác nhân thay đổi là người làm cho thay đổi xảy ra. Đây là phân công nhiệm vụ rất gay go vì nó giải quyết để vượt qua sự chống cự lại thay đổi, điều có thể chiếm tới 90% nỗ lực. Tác nhân thay đổi tạo ra kế hoạch cải tiến chi tiết, tạo điều kiện và trao đổi với mọi người trong tổ chức và giám sát thay đổi để đảm bảo thành công.

—-English version—-

 

CMMI-35

 

Question: Why do we need to improve software?  Do you have any data indicate that software need improvement?

Answer: I am very glad that you asked. There were hundred of researches in the past twenty years addressed the state of software practices, most of them indicated that software industry really need to improve. In 2005, I participated in a software industry benchmark of over 4000 software projects. We visited 186 companies in the U.S, Europe and Asia to collect data and found that:

The average software development project exceeds it’s planned budget by 90% and it’s schedule by 120%

33% of all projects are over budget

53% of projects will cost 189% of their original estimate

Only 16.2% of projects will be completed on-time and on-budget

The average time overrun is 222% of the original estimate

In large companies, only 9% of projects come in on-time and on-budget

Most failed projects were doomed from the start due to poor planning.

Based on these latest data, I concluded that software industry really needs to improve its practice quickly.

 

Question: I was amazed to see after many years people are still struggled with software process improvement issues. I do not think it is more difficult than learning new tools or new technologies.

Answer: Software Process improvement is not as easy as you think. Anyone who believes otherwise has either never tried it or has never worked on any lasting improvement. Learning new process or tools is only the beginning, there are so many human aspects to work through as you try to change the way people behave in an organization.

A new or improve process must be defined, documented, used in real project, measured for efficiency and performance, and continuously improved based on data collected. Improvement happen at the organization that means everybody in the organization, every project should adopt the changes. In order for change to happen, an infrastructure must be in place, this include a management steering group that provide vision, goals, and direction for the organization, a Software Engineering Process Group (SEPG) that communicate, facilitate, collect data and share improvement activities with the organization, and Process Action Teams (PAT) that focus on working on improvement tasks based on the assessment results. All improvement must be coordinated, facilitated and they must last for a long term.

Without this kind of infrastructure, it is difficult to make improvement last or fully institutionalize any process or technologies.

 

Question: How do you manage software practitioners effectively when technology and organization are changing rapidly?

Answer: Many managers believe that “managing” means control.  They think that if they can keep software practitioners performing in certain ways at certain times, they are successful.

But the results aren’t always what they predict because organization today is extremely complex.  Organization is composed of a diversity of people that interact and affect each other, bringing about new behaviors for the organization as a whole.  And when the environment changes, so does the behavior of its people – changing to adapt to the new changes. To succeed, manager need to recognize that they are part of the complexity, not set apart from it. They are interdependent and depend on others to accomplish goals and objectives. So the illusion of total management control is no longer valid.  In this rapid changing time, a successful manager should:

1)     Provide vision, clear direction, and strong values, but understand that changes take time.

2)     Be accessible to employees and care about them.  Get to know them, ask what they need and build trust.

3)     Understand the organization as a whole by develop empathy with employees and learn to listen to their concern. The way you listen can change people attitude and remember always respond to what you hear.

I know this is difficult because every manager is very busy with a lot of things to do but you must understand that it is the employees that make your job. We are living in a fast changing time and the best way to reap the benefit of rapid changes in today’s complex business organizations is having the best people work for you and with you. No one can do thing by themselves but everything we do depends on each others and the job of manager is getting more and more complex and only the best will be successful.

 

Question: Why is Defect Prevention at CMMI maturity level 5 instead of level 2?

Answer: Defect prevention is a process of capturing and studying defects and its trends so the organization can prevent them from happening again.

From the CMMI perspective, defect prevention requires the organization to have a standard process to collect, analyze defect data to identify root causes, review the frequency of occurrence and create a process to eliminate defects and educate software engineers of these common mistakes.

Typically at level 2, the organization is overwhelmed by schedule pressure and top priority is managing project to meet schedule. Therefore, it is very difficult to have time and resource to identify defect. Most of defect removal activities are conducted whenever time permitted.

At level 3, the organization could control project schedule to some degree and the priority is to apply “best practices” to all projects in order to achieve consistency throughout. At this maturity level, the organization could focus more on formal review and inspection to identify and remove defects.

At level 4, the organization is very stable due to a robust project management and process standardization. The key priority is focus on statistical process control based on business needs. This is where root-cause analysis happens and the defect prevention activities begin.

At level 5, due to robust data analysis and formal statistical process control, the organization could eliminate most process irregularity and prevent defect from happening.

 

Question: Why do we have to create new project plan each time? Why don’t we reuse the previous project plan to save time and money?

Answer: I know many people reuse their project plan. This works only when the new project looks like the old one. When things are different, reusing old plan or template can create problem.

Every project plan must address specific needs of particular project and even there may be some similarities, each project is also unique. Project manager must be careful when planning new project and apply critical thinking to each step. No template can address all the needs as well as all the requirements.

 

Question: What is a software process? What is your definition of an organization? We know what work and not work in our organization? Why do we need an assessment?

Answer: The software process is a set of activities that work together to produce a software product that meets cost, schedule, and quality expectations.

An organization is a collection of individuals that work together, each committed to the mission of the organization, and doing their part in supporting it.

Most people know what works and what does not work in their organization but they may not agree with each other. The key aspect of an assessment is that the team collects these views in details and uses a common framework such as the CMMI to guide and organize this collection of information. Trying to collect this information without a model such as the CMMI would be very difficult since the team may overlook something, or focus on the wrong things.

The CMMI is a well-defined and accepted model used to guide the assessment and improvement activities. When the team provides assessment findings, management can take the information with confidence and safely assume that the team has substantiated the claim within the conditions set forth for the assessment.

 

Question: How come it takes many years to move up a CMMI level? What is the most difficult level to overcome?

Answer: Each maturity level represents a set of behavior that people do in an organization. To move up a level requires a change in this behavior and change is never easy.

If you start from level 1 then you will find level 2 is very difficult since you have to start the change and overcome the resistance to change. From a technical point of view, level 2 is not difficult but it is the awareness, education, communication, and overcome the resistance to change that takes time.

If you start from level 2 then you may find level 3 is difficult because you are no longer in the “project paradigm” but move to “organization-wide paradigm”. This requires a lot of sharing of best practices and team building, which is also a very big change.

From my own experience, Level 4 is probably the biggest challenge. Unless your organization already have an excellent metrics where facts and data exist, the use of statistical control is difficult to comprehend since it requires much more skills and knowledge than the average people has. The key aspect of level 4 is the utilization of existing data into useful information for management to make decision and to fine tune the existing standard process.

Level 5 is relatively straightforward and basically an extension of what the organization already did on the journey from 1 to 4.

 

Question:  Please describe the PSP and TSP methods and identify how they fit into the process improvement activities?

Answer: The Personal Software Process (PSP) is a method that brings discipline to the individual software engineers.

PSP covers most software development tasks including requirements definition, architecture design, module development, and documentation production. Because it is at the individual level, it is designed to be a bottom up approach, improving the skill of one engineer at a time.

PSP method allows engineers an opportunity to look at their own process, review their own performance, identify their own weakness and strength quantitatively, and draw conclusion on what they need to improve. It is a very rigorous disciplined process similar to an athlete’s own quest for championship

The Team Software Process (TSP) is a method to help bring PSP trained engineers into a self-directed, high performance team. TSP allows team members to manage their work effectively by clearly define ownership, roles and responsibilities. Members track their works, their progress and performance against team’s schedule and goals.

TSP process is a team-based planning activity (called launches) to put detailed project plans in place. Team members identify tasks, dependencies and issues in a collaborative environment. Due to team effort, errors from multiple uncorrelated tasks or estimates tend to cancel out. The plans typically have an average of two milestones per week per team member. An earned values scheme is used for project tracking, i.e. when a task complete, there is a credit for the value of the task. There is no partial credit for incomplete tasks. A weekly status meeting provides the mechanism for tracking and reporting progress.  Each team member tracks and presents their status for the week. The highly task oriented TSP process ensures the accuracy measurement of progress.  Trends show up very quickly and risks are identified and eliminated. Early corrections have a much better chance of success than late drastic ones, so there is generally a much higher likelihood of avoiding major problems.  The high fidelity tracking also enables agile dynamic load balancing and critical path management, where work is continually shifted around the team in order to optimize use of resources to make planned dates. The key idea here is a commitment process, since the team develops the plan; they own it and will use it. It is a very rigorous disciplined process similar to a professional sport team game plan, designed by the coach and players.

There are different opinions regarding the use of PSP/TSP. Some people believe that PSP/TSP can be used at any CMMI level since it is focus at the individual. However, based on my own experience, this method is best used at CMMI level 4 or 5 due to the unstable nature of other lower levels. PSP/TSP is a very self-disciplined process that required significant support from management. At lower level, such as level 1 or 2, schedule pressure will definitely jeopardize any attempt to use this method. Without a standard process in place (Level 3) the utilization of PSP/TSP will not take hold since it will be viewed as “Just another flavor of the month”. Until the culture truly changes and organization begins focusing on facts and data (Level 4), PSP/TSP will emerge as the “preferred method” and will significantly change the way we practice software engineering.

 

Question: It seems that when the organization failed to improve, the SEPG is always at fault. I am very frustrated with our improvement progress, we have done everything we could but nothing happen. What do you suggest?

Answer: When improvement failed, everybody should share the blame. It is easy to point the finger at the SEPG because it is his or her job to improve the process but I believe management should share most of the burden because it is their direction and leadership that makes things happens. Let’s not dwell on who‘s fault it is but look at the way improvement is implemented in your organization.

I am sure your SEPG members have done everything they know but they need to review their approach and ask why improvement does not seem to happen. I would like to suggest the following questions:

1)     Does the SEPG actively work with projects and not spend a lot of time in their own meetings?

2)     Does the SEPG communicate new process to people in your organization?

3)     Does the SEPG engage people in the organization to develop new process?

4)     How much time does the SEPG spend advocate new practices or support people to adopt the new practice?

5)     Does the SEPG spend enough time on institutionalization?

6)     Does management review improvement status on a regularly basis?

7)     Does management encourage people to follow the standard processes?

8)     Does the organization have incentive for people to change?

9)     Does the organization recognize the early adopters?

10)  Is it possible that the organization is rushing to work on level 3 instead of institutionalizing level 2 processes?

11)  Have you consider contact external consultant for additional support?

I strongly urge every SEPG to review their approach on quarterly basis, determine what works and what does not and take corrective actions. The SEPG needs to share the results with the rest of the organization and ask for suggestions. Based on my experiences, many failures in process improvement are due to the SEPG not asking for help until it is too late.

 

Question: Why do we need measurement data to meet CMMI level 3?

Answer: The purpose of collecting measurement is to give managers the data they need to make decision about the project and organization, evaluate progress against defined goals and objectives, and take corrective actions necessary to yield the desired outcomes. Without these measures, managers cannot make informed decisions and manage their organizations effectively.

Just like when driving a car you do need to look at certain measurement instruments such as speed, gas, tachometer etc. Managers need information to manage their group and it should be collected regardless of CMMI level.

 

Question: As a programmer, I always believe that proficiency in programming will keep me on the job for a long time. However, I am very disappointed that many companies are outsourcing job oversea, it seems that the future of software is very bleak. Please comment.

Answer: Globalization happens and many programming jobs may go elsewhere but this is a trend in the industry. Most companies operate on profit and if they does not reduce their price by leverage the low wages workers elsewhere and their competitors do then they cannot compete in the open market. Some years ago, many factory jobs went away and people were upset but many get over it and found new careers in technology but now it is software turn to go elsewhere and I am sure some people will be upset.

However, not all software jobs will be outsourced. I believe in many management job will remain as well as some key positions such as system engineer, business analyst, network administration, user-interface design, project management, requirements management, software architect, and integration engineer etc.

Unless you do not want to learn new skills but prefer to do programming then the future maybe bleak. I do expect that the globalization trend will continue in the next ten years with many programming job being shifted elsewhere and programmers will be competing for fewer jobs.

 

Question: What is a Process Asset Library, its purpose and the relationship in the CMMI

Answer: A simple answer is that at CMMI level 2 projects can use whatever documented process they want, where at level 3 they should follow the best practices (Process, methods, tools) from previous projects that were identified and stored in the process asset library for re-use by other projects.

These re-usable assets establish the fact that the organizational has standard processes (OSSP) and sets the stage for the collection of measurements about the use of those assets. This becomes the basis theme for CMMI level 3 that the organization is no longer in the project stovepipe but shift to a more process managed and learning organization. The measurements being based on the use of the same basic assets across projects allows an apples to apples comparison of the results of different projects over time which forms the basis of being able to operate at maturity level 4.

At level 4 projects are managed according to a set of goals using statistical process control techniques and data collected among projects can be used to identify which assets have been the causes of variations. Assets causing variation are candidates for improvement at level 5 in Technology Change Mgmt and Process Change Mgmt key process areas where tools, methods and processes are upgraded to reduce the variation.

 

Question: Is software CMMI is focus on software practitioners only? Who else will be affected by it?

Answer: No, Software CMMI is not for software practitioners only. The Software CMMI focuses on changing the way software development work and the way software is being managed as projects (Level 2), as products (Level 3), as business products and services (Level 4) and as a key business of a company (Level 5). For improvement to happen everybody must participate and commit to make it happens.

 

Question: I am confused between the role of process improvement Champion and Change agent. As SEPG member should I be a Champion or a Change Agent?

Answer: By definition, Champion is the one who initiate, promote and maintain the improvement momentum.

To start an improvement initiative in any company requires a lot of efforts, skills and talent. The Champion must have a sound proposal and generate a lot of enthusiasm toward improvement to get support from senior management. Even when the improvement direction is in place, the Champion must promote the vision and objectives clearly to convince the middle level management to buy in and get support from the practitioners to make it works. This promotion is an on going process in order to maintain the improvement momentum. The Champion must defend the initiative against the skeptical, the negative, and the resistance to change activities and this requires a very strong commitment and patient.

By definition, Change Agent is the one who make the change happens. This is a very tough assignment since it deals with overcome the resistance to change which could be 90% of the effort. Change agent creates improvement plan in details, facilitate and communicate to people in the organization and monitoring the changes to ensure success.