Đáp: Tình huống căng thẳng ngày nay có thể làm cho người giỏi nhất trong chúng ta mất tập trung. Căng thẳng của khủng hoảng kinh tế, công nhân bị thải việc của công ti, và việc đóng cửa doanh nghiệp đã thậm chí làm cho người quản lí giỏi nhất quên mất điều là thực sự quan trọng cho họ. Mục đích của cải tiến qui trình là giảm chi phí phần mềm và cải tiến chất lượng phần mềm. Nó là cách thức bản chất để cải tiến kinh doanh và duy trì trong kinh doanh. Tôi tin bây giờ hơn bao giờ hết, bạn cần cải tiến qui trình phần mềm của mình để hỗ trợ cho doanh nghiệp của bạn vẫn duy trì tính cạnh tranh. Bạn cần biết rằng người cạnh tranh với bạn không nghỉ và nếu bạn không cải tiến, họ vẫn cải tiến.
Hỏi: Cần đặt ra bao nhiêu ngân sách dành cho cải tiến qui trình? Làm sao thầy phân nhỏ nó ra và biện minh cho nó?
Đáp: Theo kinh nghiệm của riêng tôi, ngân sách cải tiến qui trình điển hình là quãng 3%-5% ngân sách hàng năm của tổ chức. Nó có thể có vẻ nhiều nhưng nó là đầu tư mà nếu thực hiện thành công có thể đem lại lãi lớn. Đây là việc phân nhỏ của ngân sách này:
Bước đầu tiên là nhận biết về các hoạt động cải tiến. Mọi người bao giờ cũng muốn biết lí do (tại sao), qui trình (thế nào), mục tiêu (cái gì) và bản lộ trình nào (khi nào, ở đâu) mà họ phải theo. Cách tốt nhất để cho tất cả mọi người trong tổ chức nhận biết về các hoạt động là giáo dục họ về khuôn khổ CMMI và kỉ luật kĩ nghệ phần mềm. Lớp “Nhập môn CMMI” được thiết kế cho hoạt động này. Xét kích cỡ của một tổ chức điển hình có xấp xỉ 300 – 600 người, và từng lớp sẽ có xấp xỉ 60 người. Bạn cần lập lịch biểu ít nhất cho 5 tới 10 lớp cho toàn tổ chức và một lớp đặc biệt cho người quản lí (họ cần biết về CMMI nữa). Có chi phí liên kết với việc để tất cả mọi người dự lớp cả ngày nhưng dựa trên dữ liệu của chúng tôi từ nhiều năm quá khứ, phần lớn mọi người đều đồng ý rằng đây thực sự là đầu tư tốt.
Bước thứ hai là thiết lập một nhóm toàn thời chuyên dành để hỗ trợ cho hoạt động cải tiến qui trình. Cái tên thông dụng nhất cho nhóm này là Nhóm Qui trình Kĩ nghệ Phần mềm – Software Engineering Process Group or SEPG. Các thành viên của SEPG cũng cần huấn luyện thêm để làm việc của họ. Tôi mạnh mẽ tin tưởng đây là nhân tố then chốt phân biệt thành công và thất bại của cải tiến qui trình bởi vì tri thức và kĩ năng của các thành viên của SEPG là bản chất cho mọi triển khai của các hoạt động cải tiến. Kết cấu nền này cũng buộc tổ chức phải tính chi phí phụ nhưng dữ liệu của chúng tôi cũng kiểm chứng rằng đây thực sự là đầu tư tốt.
Bước thứ ba là trao đổi về mọi hoạt động cải tiến, các thành tựu, cách đo, mục đích và mục tiêu trên cơ sở đều kì cho cấp quản lí và mọi người trong tổ chức. Quản lí cải tiến yêu cầu trao đổi tốt về thay đổi, thừa nhận tiến bộ đã làm, và đo tổ chức đã cải tiến được bao xa hướng tới mục đích. Hoạt động này cũng yêu cầu thời gian và nỗ lực (chi phí) nhưng nó là một phần của hoạt động cải tiến.
Có chi phí liên kết với việc có đánh giá, thiết lập kế hoạch hành động và triển khai các hoạt động cải tiến. Phần lớn mọi người đều hội tụ vào chi phí của việc tiến hành đánh giá nhưng tôi tin tổ chức phải hội tụ vào việc triển khai kế hoạch hành động nơi nhiều người hành nghề phần mềm trong tổ chức sẽ tham gia vào các hoạt động cải tiến bên cạnh công việc thường ngày của họ và nó cũng phải tính vào nỗ lực (chi phí). Có các chi phí liên kết với quản lí, theo dõi, thu thập dữ liệu, và đo mọi hoại động cải tiến mà cũng cần được nhận diện sớm nhất có thể được để tích hợp vào tổng chi phí của cải tiến qui trình.
Như bạn có lẽ thấy từ phân tích này, phần lớn chi phí là đổ vào đầu tư cho con người trong tổ chức của bạn, huấn luyện họ, trao đổi với họ, đo thực hiện của họ, kiểm điểm công việc của họ, và vượt qua sự chống lại thay đổi để đạt tới các mục đích và mục tiêu doanh nghiệp. Cải tiến qui trình là đầu tư chính nhưng nó quả có trả lại trong tương lai, nếu bạn làm nó một cách đúng đắn và giống như bất kì đầu tư nào cấp quản lí đều phải theo dõi tiến bộ và có hành động sửa chữa khi nó dường như tạo ra kết quả không mong muốn.
Hỏi: People-CMM là gì? Điều gì xảy ra cho CMMI?
Đáp: Trong nhiều năm, tổ chức phần mềm đã chuyên môn hoá nỗ lực của nó để cải tiến công nghệ và qui trình nhưng không mấy về con người. Con người xây dựng phần mềm và làm công việc được thực hiện. Nếu họ được đối xử tốt (tức là huấn luyện, thừa nhận, đền bù) họ có thể được động viên để việc được thực hiện nhanh, tốt hơn, rẻ hơn và dùng công nghệ một cách hiệu quả hơn. Điều rất quan trọng là thừa nhận đóng góp của mọi người trong công ti và điều rất quan trọng là quản lí họ tương ứng. Mô hình trưởng thành năng lực con người – People Capability Maturity Model (P-CMM) là khuôn khổ để hấp dẫn, nuôi dưỡng, và duy trì những tài năng giỏi nhất trong công nghiệp. Nó là phần bổ sung cho CMMI chứ không thay thế. Bạn cần chấp nhận cả hai mô hình cho việc cải tiến của mình.
Hỏi: Chúng ta sống trong thời thay đổi nhanh chóng nơi mọi sự xảy ra nhanh và tác động vào cuộc sống chúng ta. Chúng ta nên làm gì để đối phó với những thay đổi này?
Đáp: Là nhà chuyên nghiệp phần mềm, có sản phẩm và dịch vụ giữ vai trò sống còn trong doanh nghiệp, chúng ta bao giờ cũng cần đánh giá những thay đổi này đang gây ra loại tác động nào lên chúng ta. Chẳng hạn: an ninh tính toán tăng lên là quan trọng cho mọi công ti, nhưng chúng ta không thể để hệ thống máy tính của mình bị khoá kín trong toà nhà được bảo vệ an ninh giống như điều chúng ta đã làm trong quá khứ. Chúng ta cần kiểm lại quan niệm về “hệ thống mở” và tác động của Internet liên quan tới những hắc khách tinh quái và chuẩn bị đối phó với “vi rút” của họ nhắm tấn công vào mục tiêu công ti.
Chúng ta cần giúp khách hàng của mình đánh giá lại hệ thống của họ, và sự phụ thuộc của họ vào Công nghệ Thông tin. Một số trong những điều này có thể bao gồm việc lập kế hoạch dự phòng nhưng chúng ta cần giúp họ xem xét lại những giả định nền tảng của họ và phát biểu về công việc và – ở chỗ thích hợp, đưa họ tham gia vào “tư duy về điều không thể tư duy được.”
Chúng ta cũng cần xem xét lại nghề nghiệp của mình trong thời kì thay đổi này. Nhiều người trong chúng ta bắt đầu hiểu thực tại là “vận may phần mềm” không còn sẵn có nữa trong thời khủng hoảng tài chính và toàn cầu hoá không còn là khái niệm mà là xu hướng. Phần lớn trong chúng ta đã từng tự hào về công việc mình làm trong nghề của mình mãi cho tới điểm này; và bây giờ chúng ta phải áp dụng kĩ năng và tri thức của mình theo cách chúng ta có thể thậm chí còn tự hào hơn về nghề của mình trong những năm tới bằng việc liên tục học những điều mới và hỗ trợ cho doanh nghiệp của mình phát đạt trong thời thay đổi này.
Hỏi: Tổ chức mức 1 của chúng tôi đã quyết định chấp nhận qui trình chuẩn phần mềm cho tổ chức từ một tổ chức mức 3 và huấn luyện cho mọi dự án tuân theo qui trình đó. Điều đó có tăng tốc cải tiến của chúng tôi và thoả mãn yêu cầu mức 3 không?
Đáp: Đây là “kịch bản lặp lại được” mà tôi đã thấy lặp đi lặp lại trong các blog trước đây: Tổ chức mức 1 vay mượn các qui trình từ các tổ chức mức 3, hay mức 4 và thậm chí mức 5, làm tài liệu chúng trong qui trình chuẩn tổ chức riêng của mình, yêu cầu tất cả các dự án phải tuân theo nó và tuyên bố thành công. Bạn có thực sự nghĩ mình có thể giảm trọng lượng bằng việc lấy bài luyện tập và chế độ ăn uống của ai đó làm của mình không? Tôi biết nhiều nhà tư vấn đã gợi ý cho công ti đó cách dễ dàng để đạt tới mức cao hơn mà không mất nhiều nỗ lực cho nên tôi thực sự muốn hỏi:
a) Làm sao bạn biết rằng các qui trình được chấp nhận sẽ có tác dụng cho tổ chức của bạn?
b) Qui trình được chấp nhận có ích và chấp nhận được cho mọi người trong tổ chức của bạn không?
c) Có bằng chứng rằng bằng việc tuân theo qui trình được chấp nhận, chất lượng, thời gian và chi phí của dự án của bạn đã được cải tiến không?
d) Tổ chức của bạn có dữ liệu chỉ ra rằng chất lượng sản phẩm của bạn, mối quan hệ khách hàng, sự hài lòng của nhân viên và mục đích doanh nghiệp được thực hiện không?
e) Bạn có tin bằng việc có chuẩn đã được làm tài liệu tổ chức của bạn tự động cải tiến không?
f) Bạn có huấn luyện mọi người dùng qui trình được chấp nhận không? Hay bạn huấn luyện họ để họ có thể qua được những câu hỏi nào đó trong kì đánh giá?
Chừng nào mọi người còn chưa hiểu qui trình mới được chấp thuận, chấp nhận nó, nhận huấn luyện về nó, dùng nó, sửa đổi nó cho khớp với nhu cầu dự án của họ, đo nó như cách họ xây dựng và bảo trì phần mềm: Chẳng cái gì đã thay đổi cả.
Tôi tin sẽ là sai lầm đi ép buộc các thay đổi lên dự án bằng việc đem qui trình chuẩn bên ngoài vào thay vì thu thập “thực hành tốt nhất” từ bên trong và thiết lập qui trình chuẩn dựa trên chúng.
Tôi tin SEPG đã vi phạm khái niệm then chốt của CMMI: “Bạn không được nhảy qua các mức.” Tổ chức mức 1 nên hội tụ vào việc thiết lập môi trường quản lí dự án có kỉ luật trước khi thiết lập qui trình chuẩn trong toàn tổ chức. Qui trình được xác định tốt từ tổ chức mức cao hơn chắc chắn là chỗ tốt để thiết lập qui trình chuẩn nhưng nó thường không có tác dụng tốt cho tổ chức mức 1. Làm cho tổ chức chấp nhận một qui trình chuẩn mới bằng việc cung cấp huấn luyện là tốt nhưng không đủ và không hiệu quả trong môi trường hỗn độn. Cải tiến qui trình bao gồm việc thay đổi cách mọi người hành xử, cách mọi người làm mọi việc và điều rất mấu chốt là làm mọi người tham gia vào việc tạo ra qui trình chuẩn dựa trên thực hành tốt nhất hiện có, không vay mượn từ ai đó.
Hỏi: Cách nhanh nhất để đáp ứng mục đích giảm chi phí trong tổ chức phần mềm là gì?
Đáp: Với giải pháp dài hạn, bạn cần nghiên cứu toàn bộ qui trình tổ chức để nhận diện các cơ hội giảm chi phí. Bạn cũng cần có dữ liệu dự án để biết chi phí chính phải gánh là ở đâu và lấy hành động sửa chữa thích hợp. Không có cách đo nào đó tại chỗ, bạn có thể thực sự không biết phải làm gì và cải tiến ở đâu.
Với giải pháp ngắn hạn, tổ chức có thể giảm cho phí bằng việc ưu tiên các dự án của mình. Cấp quản lí cần kiểm điểm các yêu cầu phần mềm, thảo luận với khách hàng để giảm phạm vi dự án, trì hoãn các dự án khác, hay thậm chí cắt bỏ những dự án không quan trọng.
Hỏi: Khác biệt giữa qui trình nghiệp vụ và tái kĩ nghệ qui trình nghiệp vụ là gì?
Đáp: Qui trình nghiệp vụ được định nghĩa là tập các hoạt động tạo ra giá trị cho công ti và khách hàng của nó. Khi công ti quyết định cách làm nghiệp vụ, họ thiết kế ra qui trình nghiệp vụ để đảm bảo rằng họ có thể quản lí mọi khía cạnh của nghiệp vụ theo cách hiệu quả và hiệu lực nhất có thể được. Tuy nhiên, qua thời gian một số qui trình có thể không còn tạo ra giá trị mong đợi nữa và phải được thay thế hay tái kĩ nghệ lại.
Tái kĩ nghệ qui trình nghiệp vụ là tập các hoạt động tạo khả năng cho công ti xoá bỏ hay giảm bớt triệt để, tất cả những hoạt động bên trong qui trình nghiệp vụ mà gia tăng ít hay không gia tăng giá trị nào cho công ti và khách hàng của nó.
Hỏi: Tôi quan tâm tới chi phí không cần thiết của việc thêm chức năng đảm bảo chất lượng phần mềm – Software Quality Assurance (SQA) vào trong tổ chức của tôi để tuân thủ với CMMI. Tôi không thấy ích lợi chút nào của việc để SQA làm cảnh sát về sản phẩm phần mềm của chúng tôi.
Đáp: Cảnh sát SQA tới vào lúc kết thúc của dự án và hội tụ vào giám định chất lượng đã hết thời rồi. Ngày nay SQA tham gia vào mọi khía cạnh của qui trình phát triển phần mềm và được thừa nhận là thành viên gia tăng giá trị của dự án nơi chất lượng là “được cấy sẵn bên trong.”
Với tổ chức mức 1, SQA hỗ trợ cho người quản lí và người phát triển trong lập kế hoạch chất lượng, cách thiết kế chất lượng trong qui trình, và loại chuẩn và công cụ nào là thích hợp nhất cho dự án. Trong vòng đời dự án, SQA tham gia vào kiểm điểm pha, đảm bảo rằng qui trình được tuân theo, và hỗ trợ việc nhận diện và loại bỏ các lỗi.
Vì bạn quan tâm tới chi phí của việc thêm chức năng SQA, ta hãy nhìn vào ví dụ đơn giản này: Dựa trên nhiều nghiên cứu, chi phí lỗi điển hình $100 cần sửa trong pha yêu cầu sẽ tốn $ 20,000 để chữa sau khi đưa ra cho khách hàng. Nếu SQA có thể ngăn ngừa chỉ mười trong những lỗi này từ lúc xảy ra, thì điều đó xứng đáng hơn lương cả năm cho người SQA (ít hơn $ 200,000). Nhớ, SQA còn nhiều hơn chỉ là ngăn ngừa lỗi xuất hiện, SQA cũng hỗ trợ cho lập kế hoạch dự án, huấn luyện chất lượng, và đánh giá công cụ, danh sách kiểm v.v.
Với tổ chức mức 2, SQA hỗ trợ cho SEPG để nhận diện “thực hành tốt nhất,” thu thập dữ liệu dự án (chất lượng, thời gian, chi phí), thiết lập thư viện tài sản qui trình, giáo dục và huấn luyện mọi người về qui trình chất lượng như phân tích căn nguyên v.v.
Với tổ chức mức 3, SQA kiểm điểm sự tuân thủ của dự án với qui trình chuẩn phần mềm của tổ chức – organizational software standard process (OSSP). SQA cũng phân tích dữ liệu chất lượng như chức năng, hiệu năng, độ tin cậy, an toàn, tính dùng được v.v. để thiết lập kiểm soát qui trình thống kế cho sản phẩm phần mềm.
Vai trò của SQA tiếp tục tiến hoá khi tổ chức trưởng thành và ở mức 4, các chức năng SEPG và SQA được tích hợp rất nhiều để hội tụ vào cả chất lượng sản phẩm và qui trình. Bằng việc hội tụ vào ngăn ngừa hơn là phát hiện, cả SQA và SEPG liên tục hỗ trợ cho cuộc hành trình cải tiến của tổ chức để cải tiến chất lượng, giảm chi phí, thời gian của hoạt động phần mềm.
Hỏi: Người hỗ trợ cho cải tiến qui trình cần làm gì để duy chỉ chỉ đạo?
Đáp: Người hỗ trợ cải tiến qui trình cần hỗ trợ sáng kiến này bằng việc bổ nhiệm cán bộ cho nó với người đúng và theo dõi tiến độ cải tiến trên cơ sở hàng tháng. Thiếu sự tham gia của nhân sự là sai lầm then chốt trong hầu hết việc cải tiến qui trình. Quyền lãnh đạo điều hành là rất mấu chốt vì cải tiến được xây dựng trên tầm nhìn và mong đợi của họ. Nếu họ không tham gia một cách cá nhân và theo dõi tiến bộ trên cơ sở đều đặn, điều đó gửi thông điệp sai cho mọi cấp quản lí rằng họ không quan tâm thêm nữa. Điều này có thể gây tác động lên hoạt động cải tiến rất nhanh chóng và phá hoại toàn bộ tổ chức. Mọi người sẽ không coi sáng kiến của cấp điều hành là nghiêm chỉnh và nếu sáng kiến thất bại đâu sẽ là cơ hội cho sáng kiến tiếp? Và nếu phần lớn các sáng kiến không được coi là nghiêm chỉnh cái gì sẽ là cơ hội để làm điều gì? Chúng tất cả đều trở thành sự phí hoài nỗ lực, tiền bạc và thời gian của công ti. Để đảm bảo điều này xảy ra, người điều hành phải để những người quản lí có trách nhiệm làm cho cải tiến xảy ra và thưởng cho thành công tương ứng.
Hỏi: Tổ chức chúng tôi đã từng làm việc về cải tiến trong nhiều năm. Chúng tôi có nhiều lần tái tổ chức và cấp quản lí thay đổi và các hoạt động cải tiến cũng đã phản ánh những thay đổi này bằng sự thăng giáng giữa các ưu tiên hàng đầu và ưu tiên thấp nhất. Chúng tôi rất thất vọng. Làm sao chúng tôi thay đổi đây? Chúng tôi phải làm gì?
Đáp: Tôi tin bạn bị thất vọng bởi vì chẳng cái gì đã được thực hiện. Bạn muốn làm mọi thứ tốt hơn nhưng không có chỉ đạo rõ ràng từ cấp quản lí nó sẽ không xảy ra. Vì tổ chức của bạn đã có nhiều lần tái tổ chức và cấp quản lí thay đổi, tôi sẽ giả định rằng đã có nhiều vấn đề găng cần được thực hiện và cấp quản lí rất bận rộn giải quyết các vấn đề trước mắt và không có thời gian cho cái gì đó khác. Chừng nào họ còn quá bận rộn tái cấu trúc tổ chức, không cải tiến nào sẽ được thực hiện đâu. Điều bạn cần là giáo dục họ về ích lợi của cải tiến và yêu cầu họ hướng dẫn và lãnh đạo. Nếu họ không được thuyết phục, chẳng cái gì sẽ làm việc.
Hỏi: Người phát triển phải viết bao nhiêu hoàn cảnh kiểm thử trong vòng đời phần mềm?
Đáp: Người phát triển phần mềm nên viết ít nhất hai kiểu hoàn cảnh kiểm thử. Hoàn cảnh kiểm thử thứ nhất ở sớm trong vòng đời phần mềm, trong việc khêu gợi yêu cầu (liệt kê cái gì cần được kiểm thử, cách nó sẽ được kiểm thử, và kết quả được mong đợi là gì) để giúp họ hiểu các yêu cầu và hoàn cảnh kiểm thử kia là ở sau khi mã được hoàn thành để giúp họ kiểm thử việc thực hiện (mã thực tại).
Hỏi: Vì lĩnh vực phần mềm vẫn thay đổi nhanh chóng, tại sao chúng ta cần cải tiến nó, dù biết rằng đằng nào nó cũng sẽ thay đổi?
Đáp: Trong khi lĩnh vực kĩ nghệ phần mềm đã thay đổi đáng kể trong vài năm qua, có những điều đã không thay đổi như kỉ luật của kĩ nghệ phần mềm. Xã hội đang trở nên phụ thuộc hơn bao giờ hết vào tính toán và nó cần phần mềm tốt hơn mà có thể được chuyển giao đúng thời gian và với giá thoả thuận được. Thái độ “bạn sẽ có nó ngay khi chúng tôi hoàn thành nó” của nhiều người phát triển phần mềm là không nhất quán với kinh doanh hàng nhiều tỉ đô la một năm, điều ảnh hưởng tới gần như mọi khía cạnh của cuộc sống chúng ta.
Trích dẫn:
Các điểm then chốt của Deming về chất lượng:
1) Tạo ra sự kiên trì cải tiến sản phẩm và dịch vụ
2) Chấp nhận triết lí mới
3) Dừng phụ thuộc vào giám định để đạt tới mỗi một mình chất lượng
4) Chấm dứt thực hành thưởng kinh doanh trên cơ sở một mình nhãn giá
5) Cải tiến thường xuyên và mãi mãi mọi qui trình về lập kế hoạch, sản xuất và dịch vụ
6) Mở lớp huấn luyện trong công việc
7) Chấp nhận và bổ nhiệm quyền lãnh đạo
8) Gạt bỏ sợ hãi
9) Phá vỡ rào cản giữa các miền cán bộ
10) Xoá bỏ các khẩu hiệu, hô hào, và mục tiêu cho lực lượng lao động.
11) Xoá bỏ các trích dẫn số về lực lượng lao động và mục đích số về quản lí
12) Loại bỏ rào cản cướp đi niềm tự hào tay nghề của mọi người
13) Xoá bỏ việc xếp hạng hàng năm của hệ thống khen thưởng
14) Khai trương chương trình giáo dục sinh động và tự cải tiến cho mọi người
15) Để mọi người trong công ti làm việc hoàn thành biến đổi
Question: In this economic crisis situation, where companies are going out of business, do we still need process improvement?
Answer: Today stressful situation can cause even the best of us to lose focus. Stresses of economic crisis, company laid-off workers, and business closing have caused even the best managers to forget the thing that really important to them. The purpose of process improvement is to reduce software cost and improve software quality. It is an essential way to improve the business and stay in business. I believe now more than ever, you need to improve your software process to support your business to stay competitive. You need to know that your competitors do not rest and if you do not improve, they will.
Question: How much budget should be set aside for process improvement? How do you break down and justify it?
Answer: Based on my own experiences, a typical process improvement budget is about 3%-5% of the organizational annual budget. It may sound like a lot but it is an investment that if successfully implement can bring significant return. Here is a breakdown of the budget:
The first step is the awareness of the improvement activities. People always want to know the reason (Why), the process (How), the objectives (What) and what roadmap (When, Where) that they must follow. The best way to have all people in the organization aware of the activities is educating them on the CMMI framework and the software engineering discipline. The class “Introduction to CMMI” is designed for this activity. Consider the size of a typical organization which is approx. 300 – 600 people, and each class will hold approx. 60 people. You need to schedule at least 5 to 10 classes for the entire organization and a special class for manager (they need to know about the CMMI too). There is cost associated with having all people to take a full day class but based on our data from past several years, most people agreed that this was really a good investment.
The second step is to establish a full time group dedicated to support process improvement activities. The most common name for this group is Software Engineering Process Group or SEPG. The SEPG members also need additional training to do their job. I strongly believe this is the key factor that discriminate success and failure of process improvement because the knowledge and skills of SEPG members are essential for all deployment of improvement activities. This infrastructure also incurs additional costs to organization but our data also verified that this was a really good investment.
The third step is to communicate all improvement activities, achievement, measurements, goals and objectives on a periodic basis to management and people in the organization. Managing improvement requires good communication of the change, acknowledge the progress made, and measure how far the organization has improved toward the goal. This activity also requires time and effort (cost) but it is a part of improvement activities.
There are costs associated with having an assessment, establish an action plan and the deployment of improvement activities. Most people focuses on the cost of conducting an assessment but I believe the organization must focuses on the deployment of an action plan where many software practitioners in organization will participate in improvement activities besides their daily work and it also incurs efforts (costs). There are costs associated with managing, tracking, collecting data, and measuring all improvement activities that also need to be identified as early as possible to be incorporate in the total cost of process improvement.
As you probably see from this analysis, most of the cost is on investing in your own people, train them, communicate with them, measure their implementation, review their works, and overcome the resistance to changes to achieve the business goals and objectives. Process improvement is a major investment but it does pay-off in the future, if you do it correctly and like any investment management must track progress and take corrective action when it does not seems to produce desirable results.
Question: What is the People-CMM? What happen to CMMI?
Answer: For years, software organization has dedicated its efforts to improve technology and process but not much in people. People build software and get the job done. If they are well treated (i.e. train, recognize, compensate) they can be motivated to get the job done faster, better, cheaper and use technology more effectively. It is very important to recognize the contribution of people to the business of a company and it is very important to manage them accordingly. The People Capability Maturity Model (P-CMM) is a framework to attract, nurture, and retain the best talents in the industry. It is a complementary to the CMMI not a substitute. You need to adopt both models for your improvement.
Question: We live in a fast changing time where things happen quickly and impact our life. What do we supposed to do to cope with these changes?
Answer: As software professionals, whose products and services play a vital role in the business, we always need to assess what kind of impact these changes are going to have on us. For example: increased computing security is important to all companies, but we can not keep our computer systems locked in a secured building like what we did in the past. We need to review the concept of “open systems” and the impact of the Internet regarding malevolent hackers and prepare to deal with their “Viruses” aim to attack corporate targets.
We need to help our customers re-evaluate their systems, and their dependence on Information Technology. Some of this may involve the contingency planning but we need to help them examine their fundamental assumptions and statement of works and – where appropriate, engage them in “thinking the unthinkable.”
We also need to re-examine our career in this changing time. Many of us begin to understand the reality that “software fortunes” were no longer available in the financial crisis time and globalization is no longer a concept but a trend; Most of us have been proud of the work we’ve done in our careers up to this point; and now we should apply our skills and knowledge in such a way that we can be even more proud of our careers in the coming years by continue to learn new things and support our business to thrive in this changing time.
Question: Our level 1 organization has decided to adopt an organization software standard process from a level 3 organization and train all projects to follow that process. Will that accelerate our improvement and satisfy the level 3 requirements?
Answer: This is a “Repeatable scenario” that I have seen over and over and mentioned in previous blogs: A level 1 organization borrows processes from level 3, or level 4 and even level 5 organizations, document them into their own organization standard process, requires all projects to follow it and declares success. Do you really think you can lose weight by having somebody exercise and diet for you? I know many consultants suggested to company that is the easy way to achieve higher levels without much effort so I really like to ask:
a) How do you know that the adopted processes will work for your organization?
b) Is the adopted process useful and acceptable to the people in your organization?
c) Is there evidence that by following the adopted process, your project’s quality, time, and cost has improved?
d) Does your organization have data indicate that your product quality, customer relationship, employee satisfaction and business goals are realized?
e) Do you believe by just having a documented standard your organization is automatically improving?
f) Are you training people to use the adopted process? Or are you training them so they can pass certain questions during the appraisal?
Unless people understand the new adopted process, accept it, receive training to follow it, use it, modify it to fit their project needs, measure it, improve it as the way they build and maintenance software: Nothing will ever change.
I believe it would be a mistake to force changes onto projects by bring in an external standard process rather than collect “best practices” from within and establish the standard process based on them.
I believe the SEPG has violated the key concept of CMMI: “You shall not skip level”. A level 1 organization should focus on establish a disciplined project management environment before establish standard process across the organization. A well-defined process from a higher-level organization is surely a good place to establish a standard process but it usually does not work well for a level 1 organization. Getting an organization to adopt a new standard process by provide training is good but not sufficient and effective in a chaotic environment. Improving the process involves changing the way people behave, the way people do thing and this is where it is critical to get everybody participating in creating a standard process based on existing best practices, not borrow from someone.
Question: What is the fastest way to meet cost reducing goal in software organization?
Answer: For long-termed solution, you need to investigate the entire organization process to identify cost-reduction opportunities. You also need to have project data to know where the major cost incurring is and take appropriate corrective actions. Without certain measurements in place, you may not really know what to do and where to improve.
In the short-termed, organization can reduce costs by prioritize its projects. Management needs to review software requirements, discuss with customers to reduce the scope of projects, postpone others, or even shutdown a few not important ones.
Question: What are the differences between business process and business process reengineering?
Answer: A business process is defined as those sets of activities that create value for a company and its customer. As company decides how to do business, they design business processes to ensure that they can manage all aspects of the business in the most effective and efficient ways as possible. However, over a period of time some processes may no longer produce the expected value or yields and have to be replaced or re-engineered.
Business process reengineering is a sets of activities that enable the company to eliminate or reduce drastically, all those activities within a business process that add little or no value to the company and its customer.
Question: I am concern with the unnecessary cost of adding Software Quality Assurance (SQA) function in our organization to comply with the CMMI. I do not see any benefit of having SQA policing our software products at all.
Answer: The SQA Police that comes at the end of the project and focus on quality inspection is gone. Today SQA participates in all aspects of the software development process and being recognized as a value-added member of the project where quality is “Built-in”.
For a level 1 organization, SQA supports managers and developers in quality planning, how to design quality into the process, and what kind of standards and tools would be best suited for the project. During the life cycle of the project, SQA participates in phase-reviews, ensure that the process is being followed, and support the identification and removal of defects.
Since you are concern with the cost of adding a SQA function, let look at this simple example: Based on several studies, a typical defect costs $100 to fix during requirement phase will costs $ 20,000 to fix after release to customers. If SQA can prevent just ten of those defects from happening, then it already worth more than a year salary for a SQA person (Less than $ 200,000). Remember, SQA is far more than just preventing defects from occurs, SQA also supports project planning, quality training, and evaluate quality tools, checklists etc.
For a level 2 organization, SQA supports SEPG to identify “Best practices”, collect project data (Quality, time, cost), establish the process assets library, educate and train people on quality process such as root cause analysis etc.
For a level 3 organization, SQA reviews project compliance with the organizational software standard process (OSSP). SQA also analyzes quality data such as functionality, performance, reliability, safety, usability etc. to establish statistical process control for software products.
The role of SQA continues to evolve as the organization maturing and at level 4, SEPG and SQA functions are very much integrated to focus on both product and process quality. By focus in prevention rather than detection, both SQA and SEPG continue to support organization’s improvement journey to improve quality, reduce the costs, time of software activities.
Question: What does a sponsor of process improvement need to do to maintain the direction?
Answer: Process improvement sponsor needs to support the initiative by staffing it with the right people and tracking improvement progress on a monthly basis. Lack of personal involvement is the key failure in most process improvement. Executive leadership is very critical since improvement is built on their vision and expectation. If they do not get involve personally and tracking progress on a periodic basis, it sends the wrong message to all management levels that they do not care anymore. This could impact improvement activities very quickly and devastate the entire organization. People will not taken executive’s initiative seriously anymore and if an initiative fail what is the chance for the next initiative? And if most initiatives are not taken seriously what would be the chance to do anything? They all become a totally waste of company’s efforts, money, and time. To ensure this from happening, executives must hold managers responsible for making improvement happen and reward success accordingly.
Question: Our organization has been working in improvement for many years. We had several reorganizations and management changes and our improvement activities also reflected these changes by fluctuate between top priority and lowest priority. We are very frustrated. How do we change? What do we do?
Answer: I believe you are frustrated because nothing is getting done. You want to make things get better but without clear direction from management it will not happen. Since your organization already had several reorganizations and management changes, I would assume that there were many critical issues that need to get done and management is very busy solving immediate problems and do not have time on something else. As long as they are too busy restructure the organization, no improvement activities will get done. What you need is to educate them on the benefit of improvement and asking them for guidance and leadership. If they are not convinced, nothing will work.
Question: How many test cases should developer write during the software life cycle?
Answer: Software developer should write at least two types of test case. The first test cases early in the software life cycle, during requirements elicitation (listing what is to be tested, how it will be tested, and what results are expected) to help them understand the requirements and another test cases after the code is completed to help them test the implementation (Actual code).
Question: Since software field keep on changing rapidly, why do we need to improve it, knowing that it will change anyway?
Answer: While software engineering field has changed significantly in the past few years, there are things that have not changed such as the discipline of software engineering. Society is becoming ever more dependent on computing and it need better software that can be delivered on time and at the agreed-upon price. The “you’ll get it as soon as we finish it” attitude of many software developers is inconsistent with a multi-billion dollar a year business that influences nearly every aspect of our lives.
Quote:
Deming’s key points on quality:
1) Create constancy of purpose for improvement of product and service
2) Adopt the new philosophy
3) Cease dependence on inspection to achieve quality alone
4) End the practice of awarding business on the basis of price tag alone
5) Improve constantly and forever every process for planning, production, and service
6) Institute training on the job
7) Adopt and institute leadership
8) Drive out fear
9) Breakdown barriers between staff areas
10) Eliminate slogans, exhortations, and targets for the workforce.
11) Eliminate numerical quotas for the workforce and numerical goals for management
12) Remove barriers that rob people of pride of workmanship
13) Eliminate the annual rating of merit system
14) Institute a vigorous program of education and self improvement for everyone
15) Put everybody in the company to work to accomplish the transformation
Theo nghiên cứu gần đây, quãng 75% thị trường phần mềm bị chi phối bởi bốn công ti: Microsoft, Oracle, IBM và SAP. Để sống còn, công ti phải hội tụ vào năng lực của mình để tăng tính hiệu quả, đưa ra sản phẩm trong thời gian ngắn hơn, và giảm chi phí mà không hi sinh chất lượng. Có nhiều cách để làm điều đó, một số công ti khoán ngoài phát triển phần mềm cho các nước chi phí thấp nơi công nhân sẵn lòng làm việc nhiều giờ với lương thấp. Điều này có thể hạ thấp chi phí của họ nhưng không đảm bảo chất lượng. Cách hạ thấp chi phí khác là tái kĩ nghệ các qui trình của họ, khử bỏ các hoạt động không cần thiết, dùng công cụ tốt hơn và thuê những kĩ sư phần mềm giỏi nhất để làm việc cho họ.
Vài năm trước, Watts Humphrey, một nhà khoa học tại Đại học Carnegie Mellon University đã thấy rằng sinh viên được đào tạo về kĩ nghệ phần mềm có thể thực hiện ít nhất 10 lần tốt hơn sinh viên được đào tạo trong khoa học máy tính hay đào tạo lập trình. Quan sát này dẫn tới nỗ lực của ông ấy để hiểu rõ hơn sự khác biệt giữa hai chương trình đào tạo này và cuối cùng đã phát triển thành một mô hình có tên là Mô hình trưởng thành năng lực phần mềm – Software Capability Maturity Model (SW-CMM). Mô hình này được dùng để đo năng lực của tổ chức phần mềm cũng như các thực hành mà người làm phần mềm phải tuân theo để phát triển phần mềm có chất lượng. Có nhiều nghiên cứu xác nhận ích lợi của mô hình này và áp dụng của qui trình kĩ nghệ phần mềm, điều có thể tạo ra kết quả lớn. Vậy mà nhiều công ti phần mềm vẫn bỏ qua mô hình này và nhiều đại học tiếp tục hội tụ vào việc dạy lập trình thay vì các môn kĩ nghệ phần mềm. Có “thái độ tiêu cực” hướng tới việc tuân theo qui trình phần mềm bởi hầu hết những người lập trình được huấn luyện trong Khoa học máy tính. Nhiều người phàn nàn về chi phí và chậm trễ liên kết với việc tuân theo qui trình và những giới hạn nó đặt lên tính sáng tạo cá nhân. Nhiều người lập trình Khoa học máy tính coi bản thân mình là “nghệ sĩ” có tự do sáng tạo phần mềm theo cách họ muốn và phần mềm là “nghệ thuật” chứ không phải là “khoa học.” Người kĩ sư phần mềm chỉ ra việc cải tiến trong năng suất và chất lượng được thấy từ việc tuân theo qui trình được xác định tốt và coi phần mềm là “khoa học’ chứ không phải là “nghệ thuật.” Với việc nhận ra ích lợi kinh doanh, nhiều kĩ sư phần mềm bằng cách nào đó bị người khác chê cười do quan niệm rằng việc tuân theo qui trình được xác định làm chậm việc phát triển phần mềm hay giới hạn tính sáng tạo. Họ chỉ ra các công ti đã thành công đạt tới SW-CMM mức cao báo cáo việc thu hồi vốn đầu tư tốt (ROI) điều nảy sinh trong việc giảm lãng phí, cho phép các kĩ sư của họ dành nhiều thời gian hơn cho việc phát triển sản phẩm chất lượng cao. Chẳng hạn, kết quả từ các kĩ sư phần mềm trên tầu con thoi khớp sát với kết quả có ý nghĩa của Boeing và nhiều công ti khác. Vâng, nhiều người lập trình vẫn còn không bị động chạm bởi những kết quả này và nhiều đại học cũng bỏ qua sự kiện rằng có nhu cầu cao về kĩ năng kĩ nghệ phần mềm trong công nghiệp phần mềm. Ngày nay tranh cãi giữa hai quan điểm: Kĩ nghệ phần mềm và Khoa học máy tính vẫn còn diễn ra trên các phòng chat internet, và bên trong cộng đồng hàn lâm.
Sau hơn 30 năm làm việc trong công nghiệp phần mềm, tôi thấy rằng mối quan hệ giữa công ti và khách hàng của nó là nhân tố chính đóng góp cho sự khác biệt giữa hai cách nhìn này. Trong các công ti phần mềm truyền thống, người lập trình được để tách rời khỏi người dùng bằng nhiều tầng những người quản lí, bán hàng và tiếp thị ở giữa. Lí do then chốt là mối bận tâm về cấp quản lí mất quyền điều khiển và nhu cầu giữ người lập trình hội tụ vào mỗi việc viết mã. (Đào tạo khoa học máy tính hội tụ hầu hết vào viết mã mà ít đào tạo về quan hệ khách hàng hay qui trình kinh doanh nghiệp vụ). Tuy nhiên, nhiều công ti phần mềm tiên tiến hiểu tầm quan trọng của sự hài lòng của khách hàng và muốn kĩ sư phần mềm của họ được tích hợp đầy đủ với người dùng để hiểu các yêu cầu của họ. Theo cách nhìn của họ, công nghệ có thể làm giảm thời gian, giảm chi phí và bằng việc có nhiều người ở giữa có thể làm chậm mọi thứ lại. (Người kĩ sư phần mềm được đào tạo trong kĩ nghệ yêu cầu và quan hệ khách hàng cho nên điều tự nhiên với họ là hoàn thành vai trò này). Khi công nghệ tăng trưởng về độ phức tạp, thách thức của việc làm việc chặt chẽ với khách hàng và người dùng tăng tầm quan trọng của nó và những công ti phần mềm tiên tiến nhất bây giờ đang thuê kĩ sư phần mềm thay vì người tốt nghiệp khoa học máy tính. Nhiều công ti phần mềm truyền thống vẫn tin rằng khách hàng không biết mấy về công nghệ, việc hiểu yêu cầu sản phẩm bằng cách cho phép người lập trình gặp họ có thể tạo ra vấn đề và làm mất số bán cho nên có những lí do để duy trì khoảng cách giữa người lập trình và khách hàng. Các công ti tiên tiến chỉ ra cùng điều này nhưng khẳng định rằng điều này chứng tỏ nhu cầu cần được tích hợp đầy đủ vào qui trình khách hàng để đảm bảo hài lòng cao trong tương lai. Họ thúc đẩy việc dùng nhiều phương pháp agile trong phát triển phần mềm và đầu tư vào quan hệ khách hàng. Họ tin cậy vào việc dùng các qui trình được xác định của kĩ sư phần mềm để giữ các hoạt động phát triển trong kiểm soát. Ngày nay, tranh cãi giữa hai quan điểm này vẫn còn diễn ra chưa thấy chấm dứt.
Vừa là giáo sư đại học và nhà chuyên nghiệp phần mềm, tôi tin rằng phần mềm là “khoa học,” không phải là “nghệ thuật.” Việc dùng các phương pháp khoa học, toán học, quản lí rủi ro, kiến trúc, các bài học rút ra, và việc áp dụng qui trình là sự khác biệt then chốt giữa chương trình đào tạo kĩ nghệ phần mềm và khoa học máy tính. Kĩ sư phần mềm được đào tạo để chia việc lớn thành nhiều nhiệm vụ nhỏ và các nỗ lực. Nỗ lực và nhiệm vụ có thể được phân lớp hoặc, “Chúng ta đã làm điều này,” hoặc “Điều này là việc mới.” Với kỉ luật kĩ nghệ cho việc sử dụng qui trình và dữ liệu, người kĩ sư phần mềm có thể thúc bẩy công việc của người khác cũng như kinh nghiệm riêng của họ để xây dựng nền tảng của “cấu phần dùng lại được.” Với những kĩ năng về kiến trúc và tích hợp hệ thống, họ có thể lắp ráp các cấu phần dùng lại thành sản phẩm mới nhanh hơn, tốt hơn và rẻ hơn. Khi họ phạm sai lầm hay khi kết quả khác với trông đợi, họ để thời gian để hiểu căn nguyên và tuân theo qui trình để làm giảm xác suất các vấn đề tương tự trong tương lai. Những bài học được rút ra này giúp người khác không phạm cùng sai lầm và cải tiến chất lượng sản phẩm phần mềm một cách có ý nghĩa. Bằng việc tuân theo qui trình dựa trên phương pháp thống kê, người kĩ sư phần mềm có thể khử bỏ nhiều lỗi bằng việc hiểu sự khác biệt giữa các nguyên nhân thông thường so với đặc biệt và cải tiến cơ hội thiết kế, xây dựng sản phẩm chất lượng cao. Điều không may là nhiều người lập trình không được đào tạo về phương pháp kĩ nghệ, kiến trúc, tích hợp, quản lí rủi ro, kiểm soát qui trình thống kê, cách đo và phân tích căn nguyên. Người lập trình có xu hướng nhằm vào việc tăng độ phức tạo như nhân tố đóng góp cho chất lượng kém của sản phẩm và phàn nàn rằng với các dự án lớn, nhiều sức ép bị đặt lên công việc của họ, yêu cầu họ làm nhiều giờ hơn.
Không có tri thức về toàn cầu hoá và đòi hỏi về tốc độ, các công ti phần mềm truyền thống có xu hướng tạo ra cấu trúc tổ chức cứng nhắc để đảm bảo công việc được thực hiện. Có những tuyến thẩm quyền và kiểm soát rõ rệt để đảm bảo không ai làm việc trên những thứ khác hơn điều hiện thời đã được phân công. Người quản lí sẽ hội tụ vào lập kế hoạch, lên lịch biểu, ngân sách, và chỉ đạo mọi người; người lập trình sẽ hội tụ vào viết mã, kiểm thử và làm tài liệu. Không may là nhiều người quản lí không được huấn luyện về khía cạnh quản lí dự án phần mềm. Một số là người lập trình giỏi được đề bạt lên quản lí. Một số bắt nguồn từ các trường kinh doanh và tài chính mà không có tri thức về phần mềm. Không được đào tạo thêm về phần mềm, nhiều người sẽ phải vật lộn với gánh nặng ước lượng, điều phối và đáp ứng đòi hỏi của khách hàng và những sức ép này sẽ đưa nhiều dự án tới thất bại. Các công ti phần mềm tiên tiến biết cách xây dựng lực lượng lao động của họ bằng những kĩ sư phần mềm được đào tạo tốt và có phẩm chất tốt. Họ tuyển lựa các kĩ sư từ các đại học nổi tiếng và cộng tác với các đại học theo nhu cầu của họ. Bằng việc có các kĩ sư có kĩ năng duy nhất bổ sung cho nhau, các công ti này thường có các tổ công tác tự quản, có khách hàng tham gia và nhỏ. Họ thúc bẩy các công nghệ và công cụ hiện đại, nhưng điều quan trọng nhất là họ thúc bẩy các hoạt động tổ để tất cả cùng làm điều đó. Họ nghĩ rằng việc tích hợp như vậy của các tổ nhỏ đưa tới kết quả nhanh hơn với sản phẩm đáp ứng nhu cầu khách hàng. Bằng việc áp dụng các phương pháp khoa học như phân tích căn nguyên, kiểm soát qui trình thống kê, họ có thể giảm sai lầm bởi vì nguyên nhân của lỗi đã được khử bỏ ra ngoài hệ thống. Đây là lí do tại sao phương pháp agile đi đôi với kiểm soát qui trình thống kê có thể có ích lợi cho cả công ti cũng như khách hàng của họ.
—-English version—-
Software Industry
Globalization demands software companies to have quality products at lower costs and this trend create more competition among companies. According to recent studies, about 75% of software market is dominated by four companies: Microsoft, Oracle, IBM and SAP. To survive, company must focus on their ability to increase efficiency, release products in a shorter time, and reduce costs without sacrificing quality. There are several ways to do that, some companies outsource software development to lower cost countries where workers willing to work long hours at lower pay. This may lower their costs but do not guarantee the quality. Other lower their costs by re-engineering their processes, eliminating unnecessary activities, obtaining better tools, and hire the best software engineers to do works for them.
Several years ago, Watts Humphrey, a scientist at CarnegieMellonUniversity found that students trained software engineering can perform at least 10 times better than students trained in computer science or programming trainings. This observation led to his effort to better understand the differences between the two training programs and eventually developed a model called the Software Capability Maturity Model (SW-CMM). This model is used to measure the capability of software organization as well as practices that software people must follow to develop quality software. There are many studies confirming the benefits of this model and the application of a software engineering process that can produce great results. Yet many software companies still ignore this model and many universities continue to focus on teaching programming rather on software engineering disciplines. There is a “negative attitude” toward following a software process by most programmers trained in Computer Science. Many complain about the costs and the delays associated with following a process and the limits it places on their individual creativity. Many Computer Science programmers consider themselves “artists” with a freedom to create softwares the way they want and software is an “art” not a “science”. Software engineers point out the improvements in productivity and quality found in following a well defined process and consider software is a “science” not an “art”. By realizing the business benefits, many software engineers are somewhat amused by the notions that following a defined process slowdown software development or limits creativity. They point to companies that have successfully achieved high SW-CMM levels report good returns on their investments (ROI) which resulted in reducing waste, allowing their engineers to spend more time developing high quality products. For example, the results from the shuttle on-board software engineers align nicely with the significant results from Boeing and numerous other companies. Yet, many programmers remain untouched by these results and many universities also ignore the fact that there is a high demand of software engineering skills in the software industry. Today the debate between two views: Software engineering and Computer Science is still going on in internet chat rooms, and within academic community.
After working more than 30 years in the software industry, I found that the relationship between a company and its customers is a major factor that contributed to the difference between these two views. In traditional software companies, programmers are kept away from the users with many levels of managers, sales and marketing people in between. The key reason is a concern about management losing control and the need to keep programmers focused on writing code. (Computer Science training is focusing mostly on coding with limit training in customer relationship or business processes). However, more advanced software companies understand the important of customer satisfaction and want their software engineers fully integrated with the users to understand their requirements. From their view, technology can decrease time, reduce costs and by having many people in between can slow things down. (Software engineer are trained in requirements engineering and customer relationship so it is natural for them to fulfill this role). As technology grows in complexity, the challenge of working closely with customers and users grows in its importance and most advanced software companies are now hiring software engineers rather than computer science graduates. Many traditional software companies still believe that customers do not know much about technology, understand product requirements by allowing programmer to meet with them could create problems and lose a sale so there are reasons to maintain the distance between programmers and customers. Advanced companies point to the same things but assert that this demonstrates the need to be fully integrated into their customer process to ensure higher satisfaction in the future. They promote the use of more agile methods in software development and invest in customer relationships. They trust their software engineers’ use of defined process to keep development activities under control. Today, the debate between two views is still going on with no end in sight.
As both a university professor and software professional, I believe that software is a “science”, not an “art”. The use of scientific methods, mathematics, risk management, architecture, lessons learned, and the application of process are the key difference between software engineering training and computer science program. Software engineers are trained to breakdown large work into tasks and efforts. Effort and task can be classified as either, “We have already done this,” or “This is new work.” With engineering discipline for employing process and data, software engineer can leverage the work of others as well as their own experiences to build a foundation of “Reusable components”. With skills in architecture and system integration, they can assemble these reuse components into new product faster, better and cheaper. When they make mistakes or when results differ from expectations, they take time to understand the root cause and follow a process to reduce the probability of similar problems in the future. This lessons learned help others from not making the same mistake and improve the quality of software products significantly. By following process based on statistical methods, software engineers can eliminate many defects by understand the different between common vs. special causes and improve the chance of design, build a highly quality product. Unfortunately, many programmers are not trained in engineering methods, architecture, integration, risk management, statistical process control, metrics and root cause analysis. Programmer have a tendency to point to the increase of complexity as a factor that contribute to the poor quality of products and complain that with large size projects, more pressure are putting on their works, require them to work longer hours.
Without knowledge about globalization and the demand for speed, traditional software companies tend toward creating rigid organizational structures to ensure the work gets done. There are clear lines of authority and control in order to ensure no one is working on things other than what is currently assigned. Managers will focus on planning, scheduling, budgeting, and directing people; Programmers will focus on coding, testing and documenting. Unfortunately, many managers are not trained in the managing aspect of software project. Some are good programmers that getting promoted into management. Some come from business and finance schools with no knowledge of software. Without additional software training, many will struggle with the burden of estimating, monitoring and meeting customers’ demand and these pressures will drive many projects to failure. Advanced software companies know how to build their work force with well-trained and well qualified software engineers. They recruit engineers from well known universities and collaborate with universities on their needs. By having engineers with unique skill that complements others, these companies usually have small, customer-involved, self-directed work teams. They leverage modern technologies and tools, but most importantly they leverage the teamwork activities to do it all. They think that such integration of small teams leads to faster results with products that meet customers’ needs. By applying scientific methods such as root cause analysis, statistical process control, they can reduce mistakes because the cause for errors has been eliminated out of the system. This is the reason that why agile method coupled with the use of statistical process control can benefit both the company as well as their customers.
