Đáp: Theo định nghĩa, Qui trình phần mềm chuẩn của tổ chức Organization Standard Software Process (OSSP) là tập các qui trình được chấp thuận để dùng trong một tổ chức. Chúng nên bắt nguồn từ “những thực hành tốt nhất” trong tổ chức điều có nghĩa là phần lớn chúng đã tồn tại và đang được dùng trong tổ chức. Việc của SEPG là nhận diện, tổ chức và lưu giữ chúng ở một chỗ chung để mọi người có thể dùng chúng một cách hiệu quả.
SEPG không nên là “người tạo ra OSSP” mặc dầu tôi có biết một số thành viên SEPG thích dành nhiều năm tạo ra OSSP bằng việc viết các yếu tố, thủ tục, và khuôn mẫu nơi cô lập và tin mọi người nên dùng chúng. Loại OSSP này hiếm khi có tác dụng vì phần lớn những người hành nghề phần mềm sẽ bác bỏ nó bởi vì nó là cái gì đó bị áp đặt lên họ điều họ không có đóng góp vào. Để làm cho OSSP là thành công, SEPG phải thu thập “các thực hành tốt nhất” hiện có, cái bắt nguồn từ những người hành nghề bên trong tổ chức và đơn giản hoá chúng cho dễ dùng và trao đổi với mọi người bên trong tổ chức để cho họ có thể dùng lại chúng thay vì phát minh lại thực hành khác.
SEPG không phải là “người áp đặt OSSP”. Nếu người hành nghề cảm thấy rằng SEPG đang áp đặt cái gì đó lên họ, họ sẽ chống lại và từng thực hành then chốt sẽ trở thành trận chiến then chốt. Việc của SEPG là tạo điều kiện thuận lợi, phối hợp, và trao đổi mọi cơ hội cải tiến và vật phẩm cho mọi người trong tổ chức do đó, SEPG không nên viết bất kì tài liệu dài nào để được đặt lên giá.
Người quản lí không phải là “người áp đặt OSSP”. Việc của người quản lí là cung cấp chỉ đạo, trao đổi và động viên mọi người cải tiến qui trình của họ. Người quản lí nên xác định mục đích doanh nghiệp của tổ chức – điều họ muốn hoàn thành, ưu tiên hoá và loại bỏ mọi chướng ngại đang kìm giữ họ khỏi việc đáp ứng những mục đích đó. Những người hành nghề bao giờ cũng muốn cải tiến ở những khu vực làm họ thất vọng nhưng họ thích giải pháp thực hành hay cái gì đó được chứng minh làm việc được hơn là khái niệm trừu tượng nào đó từ một chuyên gia trong tháp ngà.
Để cải tiến, mọi người phải làm việc cùng nhau như một tổ hướng tới mục đích chung. Mục đích không nên là ‘mức’ mà nên là tổ chức phần mềm tốt hơn tạo ra sản phẩm và dịch vụ chất lượng cao.
SEPG cần làm việc chặt chẽ với người hành nghề, hiểu nhu cầu của họ và cố gắng làm cho việc của họ dễ dàng hơn bằng việc thúc đẩy chia sẻ “thực hành tốt nhất” qua OSSP. Họ phải dành nhiều thời gian hơn để làm cho mọi người dùng OSSP và ít thời gian để xác định nó. Họ phải giữ cách tiếp cận của họ đơn giản, và nhớ rằng đó là nỗ lực làm việc tổ, đừng buộc miếng gỗ vuông vào trong cái hố tròn.
36.02 Hỏi: Mục đích tốt hơn cho cải tiến qui trình là gì nếu chúng tôi không dùng các mức trưởng thành?
Đáp: Mục đích của cải tiến qui trình bao giờ cũng là được gióng thẳng với mục đích doanh nghiệp của tổ chức, dù mục đích đó là bất kì cái gì. Mức trưởng thành không nên là mục đích bởi vì nó không ngụ ý gì mấy trong thế giới doanh nghiệp. Tôi biết vài tổ chức đã đặt mục đích cải tiến để có phần mềm chất lượng tốt hơn bởi vì nó là tốt bất kể liệu mục đích này có nhất quán với mục đích doanh nghiệp hay không. Đây là sai lầm bởi vì điều gì xảy ra nếu mục đích doanh nghiệp không phải là phần mềm tốt hơn mà là thời gian ra thị trường nhanh hơn? Một tổ chức mà có thể tạo ra phần mềm chất lượng cao nhất có thể ra khỏi kinh doanh nếu không ai muốn mua phần mềm của họ bởi vì ai đó khác đã chi phối thị trường. Trong môi trường cạnh tranh cao này cái gì đó là sản phẩm đầu tiên trên thị trường là điều bản chất.
Tôi tin mục đích cải tiến tốt bao giờ cũng phải được xác định trong hoàn cảnh doanh nghiệp chứ không tuỳ ý là bất kì cái gì có vẻ tốt.
36.03 Hỏi: Nhân tố gì là then chốt cho việc xây dựng tổ thành công để triển khai cải tiến qui trình phần mềm?
Đáp: Dựa trên kinh nghiệm của tôi, tin cậy là nhân tố quan trọng nhất. Về căn bản, tin cậy là thuật ngữ khá bao quát chỉ ra sự đồng ý trong các thành viên tổ để tôn trọng cam kết của họ cùng làm việc với nhau và chia sẻ các mục đích và mục tiêu chung. Nếu bạn có “chương trình nghị sự ngầm”, bạn không thể được tin cậy trong tổ. Mọi tổ đều phải có các mục đích chung bởi vì không có các mục đích được xác định rõ ràng, các thành viên tổ đương nhiên sẽ có xu hướng thái độ thụ động và làm việc với các chủ định chéo nhau. Người lãnh đạo tổ phải phát biểu rõ ràng mục đích mục tiêu ngay từ lúc ban đầu hình thành tổ và đều đặn đo tiến bộ theo các mục đích đó.
Để hiệu quả, tổ cũng phải duy trì các qui trình tổ được thiết lập mà mô tả cho các vai trò, trách nhiệm và cách họ vận hành cùng nhau như một tổ. Về căn bản các vai trò và trách nhiệm này nói ai làm gì dựa trên thoả thuận theo giao thức để tránh xung đột giữa các thành viên tổ. Thỉnh thoảng, người lãnh đạo tổ nên đánh giá lại các qui trình này và xác định cái nào hữu dụng và cái nào cần được bổ sung hay tăng cường. Người lãnh đạo tổ nên chắc rằng ở nơi cần, mọi thành viên phải cung cấp cái vào cho quyết định nhóm.
Trong khi có thể không có kèm cặp bên trong tổ, các thành viên của tổ nên hỗ trợ nhau một cách không chính thức và động viên các thành viên tổ chia sẻ kinh nghiệm và học lẫn nhau. Người lãnh đạo tổ nên đánh giá cái gì có tác dụng và cái gì không tác dụng dưới dạng đóng góp của các thành viên tổ và phân công nhiệm vụ và vai trò tương ứng. Điều rất quan trọng là thừa nhận mọi sự hoàn thành, dù lớn hay nhỏ bởi vì thành công bao giờ cũng tới như nỗ lực tổ chứ không cá nhân.
36.04 Hỏi: Thực hành tốt nhất là gì? Có quá nhiều ý kiến chuyên gia. Tôi muốn câu trả lời đơn giản.
Đáp: Theo định nghĩa “Thực hành tốt nhất là điều bạn làm tốt nhất và có dữ liệu chứng minh cho nó.” Chẳng hạn, có hai qui trình tiến hành kiểm điểm mã. Qui trình A tìm ra 3 lỗi trên KLOC nhưng qui trình B tìm ra 5 lỗi trên KLOC trong cùng chương trình đó, do đó B là tốt hơn A bởi vì nó tìm ra nhiều lỗi hơn.
Thực ra, có thể khó so sánh qui trình giống như thế cho nên cách tiếp cận thông thường có thể được dùng. Chẳng hạn “Làm khách hàng và người dùng tham gia trong qui trình khêu gợi yêu cầu” có thể được coi là thực hành tốt nhất bởi vì nó giúp cho người phát triển hiểu rõ hơn nhu cầu thực của người dùng. “Duy trì ma trận dõi vết” cho mọi dự án cũng là thực hành tốt nhất bởi vì nó giúp móc nối yêu cầu với sản phẩm công việc, một cách tường minh. “Ưu tiên hoá mọi thay đổi và kiểm nghiệm với người dùng” là thực hành tốt nhất bởi vì nó giúp người phát triển làm việc trên những thay đổi quan trọng nhất mà khách hàng cần.
36.05 Hỏi: Việc của người quản lí là quản lí qui trình hay con người? Chúng tôi bị lẫn lộn về người quản lí làm quản lí theo qui trình và làm quản lí theo con người.
Đáp: Việc của người quản lí là quản lí cả qui trình và con người. Bạn quản lí qui trình bằng cái đầu của mình và quản lí con người bằng trái tim của mình.
Thỉnh thoảng chúng ta quá hội tụ vào qui trình và quên mất rằng con người tạo nên tổ chức. Không có con người bạn có thể có nhiều qui trình nhưng chẳng cái gì được làm. Tôi tin người quản lí tốt nên dành 80% thời gian để quản lí con người bởi vì mọi người bao giờ cũng nhìn vào người quản lí về chiều hướng và công nhận. Họ có thể không nhớ điều người quản lí đã nói hay làm nhưng họ bao giờ cũng nhớ cách người quản lí làm cho họ cảm thấy. Tất cả chúng ta đều nhớ các ví dụ khi người quản lí làm cho chúng ta có cảm giác tốt hay làm cho chúng ta cảm thấy không được đánh giá cao.
Một lời động viên có thể làm cho một người cảm thấy được công nhận và được đánh giá cao và một lời phê bình có thể làm cho mọi người cảm thấy vô nghĩa. Cảm giác tích cực sẽ nảy sinh trong việc đóng góp ở trên và bên ngoài tiếng gọi nghĩa vụ và cảm giác tiêu cực sẽ làm nảy sinh trong việc làm chỉ điều nó phải được làm để đáp ứng yêu cầu tối thiểu. Thành công hay thất bại của dự án hay của tổ chức tuỳ thuộc lớn vào vai trò và kĩ năng của người quản lí và người ta phải không nên coi nhẹ nó.
36.06Hỏi: Tại sao chúng tôi phải tuân theo chuẩn châu Âu như ISO 9000?
Đáp: ISO 9000 KHÔNG phải là chuẩn châu Âu mà là tiêu chuẩn quốc tế được chấp nhận. Tuy nhiên, là một chuẩn chất lượng, hướng dẫn của ISO 9000 là rất rộng và tổng quát cho nên nó có thể áp dụng cho nhiều khu vực. Vấn đề với ISO 9000 là trong thực hiện – chuẩn bị cho tổ chức được chứng nhận ISO 9000. Điều này có nghĩa là làm mọi thứ mà chuẩn mô tả, kể cả mọi chi tiết bất kể liệu tổ chức có tin vào nó là quan trọng hay không. Ích lợi then chốt của chứng nhận ISO là ở chỗ nó cho phép bạn chứng minh cho khách hàng của bạn rằng bạn có tại chỗ qui trình quản lí chất lượng. Điều này được thẩm tra bằng dấu vết tài liệu, cái làm tài liệu mọi cơ chế cần thiết thật chi tiết về qui trình quản lí chất lượng như được yêu cầu bởi chuẩn ISO standards.
Tôi tin mọi công ti làm kinh doanh ở hải ngoại đều cần tuân theo chuẩn quốc tế bất kể trạng thái chuẩn địa phương của nó.
36.07 Hỏi: Thầy giải quyết các yêu cầu thay đổi thường xuyên thế nào từ những khách hàng có đầu óc thay đổi thường xuyên?
Đáp: Bạn cần nhiều trao đổi, kiên nhẫn và kĩ năng. Đừng bao giờ giả định cái gì, bao giờ cũng viết ra yêu cầu và kiểm nghiệm với người dùng. Bạn có thể dùng kĩ thuật bản mẫu hay bản thử màn hình để đi tới thống nhất với người dùng. Nhiều yêu cầu “thay đổi thường xuyên” là do “người sai” xác định yêu cầu hay nắm bắt yêu cầu cho nên bạn cần nhận diện người dùng thực.
Nếu yêu cầu tiếp tục thay đổi, bạn có thể phải chấp nhận cách tiếp cận dựng gia tăng ở nơi các yêu cầu được xác định theo phân giai đoạn.
36.08 Hỏi: Chúng tôi mệt mỏi về tranh cãi vô nghĩa về cải tiến qui trình trong các tổ khác nhau trong tổ chức của chúng tôi. Chúng tôi muốn tự mình cải tiến qui trình. Chúng tôi có thể đạt tới các mức 3, 4, và 5 mà không có phần còn lại của tổ chức không?
Đáp: Ai dừng nhóm bạn lại khỏi việc cải tiến bản thân các bạn? Nếu nhóm của bạn có thể giảm lỗi, thời gian chu kì, quản lí dự án tương ứng theo dự phóng chi phí và lịch biểu, đạt tới sự hài lòng của khách hàng và có dữ liệu chứng minh rằng bạn thực sự cải tiến thì tại sao bạn quan tâm về mức CMM vô nghĩa?
Nhiều người dành thời gian trong các cuộc tranh cãi dài dòng mà chẳng biết rằng cải tiến là hành động chứ không phải là chủ đề cho thảo luận. Thỉnh thoảng họp là cách tinh ranh để chống lại thay đổi hay hành động làm cái gì đó. Đôi khi có vẻ bận rộn là cách để che đậy sự kiện là họ không biết cách làm cho tiến bộ có tác dụng. Đôi khi mọi người dùng các “từ đao to búa lớn” hay “cách nói kĩ thuật” để né tránh chủ đề đơn giản thực của cải tiến qui trình.
36.09 Hỏi: Ích lợi của thu thập dữ liệu lỗi là gì bên cạnh việc sửa lỗi?
Đáp: Dữ liệu lỗi (cả trước và sau đưa ra) có thể cung cấp nhiều thông tin. Dữ liệu lỗi cung cấp cái nhìn sâu vào trong qui trình phát triển phần mềm và tính hiệu quả của từng pha của vòng đời phần mềm. Chẳng hạn, nếu lỗi cứ tăng lên qua thời gian, chúng ta phải hội tụ nỗ lực của mình vào sự thích hợp của pha kiểm thử, hay thiết kế hay pha yêu cầu. Tỉ lệ lỗi cũng có thể được dùng để xác định liệu sản phẩm có đủ ổn định để đưa ra cho khách hàng không. Số lỗi cao được nhận diện trong kiểm điểm pha có thể chỉ ra vấn đề nào đó trong pha đó và người quản lí dự án phải quyết định liệu phần mềm có thể được đưa ra vào pha sau hay không. Dữ liệu lỗi có thể được nạp lại vào trong qui trình ước lượng để ước lượng số các lỗi trông đợi cho một kiểu việc đặc biệt.
36.10 Hỏi: Chúng tôi đã dùng CMMI trong nhiều năm với nhiều tổ chức thế đã đạt tới thành công lớn. Làm sao chúng tôi không học được từ nhau mà vẫn tiếp tục tranh đấu?
Đáp: Công ti chúng tôi rất lớn với nhiều nhóm đa dạng và sẽ mất thời gian cho mọi người nhận ra rằng việc học từ nhau và chia sẻ thực hành tốt nhất là tốt hơn tranh đấu để làm nó trong cô lập. Đó là lí do tại sao tôi đã thành lập Mạng cải tiến qui trình phần mềm Software Process Improvement Network (SPIN) năm 1992 như diễn đàn để chia sẻ kinh nghiệm cải tiến. Bao giờ cũng là khôn ngoan khi đi học cách những điều đang diễn ra tốt từ người khác và xác định liệu cách tiếp cận của bạn có cần được làm mịn không.
Khi mọi người tham gia vào cải tiến qui trình, người ta phải thường xuyên tự hỏi mình “Cái gì đã diễn ra tốt và cái gì đã không làm việc tốt? Cái gì là vấn đề ngăn cản tổ chức không đạt tới mục đích? Cái gì có thể được làm khác đi để làm cho công việc cải tiến?”
36.11 Hỏi: Xin thêm khôi hài vào chủ đề khô khan về cải tiến qui trình.
Đáp: Nếu cải tiến qui trình là “chủ đề khô khan” thì chúng ta phải tìm “chủ đề ướt át” như con thuyền của Noah. Cho nên đây là nó …
Mọi thứ tôi cần biết về cải tiến qui trình, tôi đã học từ con thuyền của Noah.
1) Đừng bỏ lỡ con thuyền (hay hoạt động cải tiến)
2) Nhớ lấy, chúng ta đang trong cùng con thuyền (hay tổ chức)
3) Lập kế hoạch trước, trời không mưa khi Noah dựng thuyền (Nhớ tới KPA lập kế hoạch dự án)
4) Duy trì chuẩn bị, cho dù ở 600 tuổi, ai đó có thể yêu cầu bạn làm cái gì đó rất lớn (sẵn sàng là tác nhân thay đổi, kể cả vào thời xưa như tất cả những người ở thời bùng nổ trẻ em)
5) Đừng nghe lời chỉ trích, hay dành thời gian vào họp hành chỉ để nói về việc cần được làm (Nhiều thứ cho phối hợp liên nhóm)
6) Xây dựng tương lai của bạn trên nền cao (trưởng thành mức 5)
7) Với mục đích an toàn, luôn đi cặp đôi (làm việc trong tổ)
8) Nhanh không phải bao giờ cũng tốt hơn. Sên trên cùng đường với báo hoa. (Chính chất lượng mới phải tính tới)
9) Khi bị căng thẳng, nổi một chốc (Đừng coi việc của bạn quá nghiêm trọng – thảnh thơi và tham dự SPIN)
10) Thuyền được làm ra bởi ít người thôi. Con tầu Titanic được một uỷ ban xây dựng. (Nghĩ về OSSP hử!)
36.12 Hỏi: Ý nghĩ của thầy là gì về học trường sau đại học ngay sau khi tốt nghiệp đại học? Hay người ta nên tham gia lực lượng lao động trước?
Đáp: Có vài quan điểm về liệu người ta có nên vào thẳng trường sau đại học hay tham gia lực lượng lao động trước.
Một số người tin rằng khi bạn còn trẻ và có động cơ bạn nên hoàn thành trường sau đại học trước khi làm việc vì công việc sẽ làm chậm bạn lại. Một khi bạn bận rộn với nghề nghiệp của mình thì khó quay lại trường. Khi bạn kiếm lương, trở lại trường là việc tụt lùi về kinh tế (không làm mà chi tiền).
Tuy nhiên, tôi tin rằng nhiều thanh niên tuổi đại học thực sự không biết nhiều về cuộc sống, và cuộc sống làm việc và phải đi làm việc trong vài năm để học thêm – rồi mới quyết định. Vào lúc đó, bất kì cái gì bạn muốn, quay lại trường hay tiếp tục làm việc, bạn sẽ ra quyết định đúng.
Cuộc sống là về học liên tục và cuộc sống làm việc là kinh nghiệm mà có thể giúp bạn hình thành nên tương lai của bạn cho tốt hơn. Điều gì xảy ra nếu bạn kết thúc trường sau đại học, đi làm và thấy rằng bạn thực sự không thích việc làm đó?
Mọi người đổi ý họ thường xuyên và thay đổi là quan trọng cho nên đừng tự khoá mình vào cái gì đó bạn không biết thật rõ lắm.
36.13 Hỏi: Thầy có lời khuyên nào về tổ SEPG mới?
Đáp: Say đây là 10 lời khuyên của tôi cho thành viên SEPG:
Nhận giúp đỡ từ chuyên gia chuyên lĩnh vực sớm và thường xuyên
Bạn phải dự ứng nhiều hơn bạn vẫn thường vậy
Đừng ước lượng thấp thời gian cần cho hoàn thành các nhiệm vụ:
Gần như mọi hoạt động đều lâu hơn bạn nghĩ
Xác định phạm vi của cải tiến sớm sủa
Bắt đầu với bản kế hoạch cũng giống như bạn bắt đầu dự án
Đừng mong đợi được bảo cho điều phải làm
Cải tiến là cuộc hành trình không phải là đích đến và trong cuộc hành trình này, phẩm chất chân thực và toàn vẹn là không thể thương lượng được
Để thời gian để hình thành nên tổ thành công:
Biết các thành viên tổ của bạn
Phát triển tin cậy trong tổ của bạn
Học cách thoải mái cùng họ
Liên tục xây dựng tổ năng động
Thiết lập qui trình tổ
Nhận diện rõ ràng vai trò, trách nhiệm và thẩm quyền
Phân chia nhiệm vụ giữa các khả năng của thành viên tổ để thực hiện không phải điều họ muốn
Điều đó bao giờ cũng mất thời gian lâu hơn và nhiều nỗ lực hơn mong đợi
Sẵn sàng cho việc chống lại thay đổi
Đọc, học và chia sẻ nhiều hơn – Không ai là hoàn hảo
Hiểu khó khăn mà bạn đối diện và chuẩn bị trước khi bạn bắt đầu cuộc hành trình
English version
CMMI#36
36.01 Question: Should SEPG or software practitioners create the Organization Standard Software Process (OSSP)? Who should enforce it, manager or SEPG?
Answer: By definition, Organization Standard Software Process (OSSP) is a set of processes approved for use in an organization. They should come from “best practices” in the organization that means most of them already exist and being used in the organization. The job of the SEPG is to identify, organize and store them in a common place so people can use them effectively.
SEPG should not be “OSSP creator” although I do know some SEPG members would like to spent years creating the OSSP by writing process elements, procedures, and templates in isolation and believe people should use them. This kind of OSSP rarely works since most software practitioners will reject it because it is something being forced upon them which they do not have inputs. To make OSSP a success, SEPG must collect existing “Best practices”, which come from practitioners within the organization, organize and simplify them for ease of use and communicate to people within the organization so they can re-use them instead of re-invent another practice.
SEPG is not “The OSSP enforcer”. If practitioners feel that SEPG is imposing something on them, they will resist and each key practice will become a key battle. The job of SEPG is to facilitate, coordinate, and communicate all improvement opportunities and artifacts to people in the organization therefore, SEPG should not write any lengthy documents to be put on the shelves.
Manager is not “The OSSP enforcer”. The job of manager is to provide direction, communicate and motivate people to improve their process. Manager should define organization business goals – what they want to accomplish, prioritize and removing any obstacles that are holding them back from meeting those goals. Practitioners always want to improve on the areas that frustrate them but they like a practical solution or something that is proven working than some abstract concept from an expert in an ivory tower.
To improve, everybody should work together as a team toward a common goal. The goal should not be a ‘Level’ but a better software organization that produce a highly quality product and services.
SEPG needs to work closely with practitioners, understand their needs and try to make their job easier by promoting the sharing of “Best practices” via the OSSP. They must spend more time to get people use the OSSP and less time to define it. They must keep their approach simple, and remember that it is a teamwork effort, do not force a square peg into a round hole.
36.02 Question: What would be the better goal for process improvement if we do not use the maturity levels?
Answer: The goal of process improvement should always be aligned with the business goal of the organization, whatever that goal is. A maturity level should not be a goal because it does not mean much in a business world. I know several organizations have set improvement goal of better quality software because it sound good regardless of whether this goal is consistent with the business goal or not. This is a mistake because what happen if the business goal is not better software but faster time to market? An organization that can produce the highest quality software could go out of business if no one wants to buy their software because somebody else already dominates the market. In this highly competitive environment sometime being the first product in the market is essential.
I believe good improvement goal should always be defined in a business context not arbitrarily anything that may sound good.
36.03 Question: What are the key factors to build a successful team to deploy software process improvement?
Answer: Based on my experiences, trust is the most important factor. Basically, trust is a catch-all term indicating an agreement among team members to honor their commitments to work together and share common goals and objectives. If you have “hidden-agenda”, you cannot be trusted on the team. Every team must have common goals because without clearly defined goals, team members will tend to drift off course and work at cross purposes to one another. The team leader must clearly state the goals and objectives at the beginning of the team formation and periodically measure the progress against those goals.
To be effective, the team must also maintain an established team processes which describe roles, responsibilities and how they operate together as a team. Basically these roles and responsibilities stated who is doing what based on an agreed upon protocol to avoid conflict among team members. Occasionally, team leader should re-evaluate these processes and determine which are useful and which need to be added or reinforced. The team leader should make sure that where necessary, all members should provide input on group decision. While there may be no formal mentoring within a team, members of the team should informally support each others and encourage team members to share experiences and learn from one another. Team leader should evaluate what worked and what didn’t in terms of individual team member contributions and assign tasks and role accordingly. It is very important to recognize any accomplishments, large or small because success always comes as a team effort not an individual.
36.04 Question: What is a best practice? There are too many expert opinions. I want a simple answer.
Answer: By definition “Best practice is thing you do best and have data to prove it”. For example there are two processes of conducting code review. Process A found 3 defects per KLOC but process B found 5 defects per KLOC in the same program, therefore B is better than A because it found more defects.
In practice, it may be difficult to compare process like that so a common sense approach could be used. For example “Involve customers and users during the requirements elicitation process” can be considered a best practice because it helps developer better understand real needs of users. “Maintain a traceability matrix” for every project is also a best practice because it helps link the requirements to work products, explicitly. “Prioritize all changes and validate with user” is a best practice because it helps developer work on the most important changes that the customer needs.
36.05 Question: Is manager’s job to manage process or people? We are confused about process-managed and people-managed manager.
Answer: A manager’s job is managing both the process and the people. You manage the process by your head and people by your heart.
Sometime we are too focusing on the process and forget that people make up the organization. Without people you may have a lot of processes but nothing will get done. I believe a good manager should spend 80% of the time managing people because people always look to manager for direction and validation. They may not remember what a manager said or done but they always remember how a manager makes them feel. We all remember instances where a manager made us feel good or made us feel unappreciated. A word of encouragement can make a person feels validated and appreciated and a word of criticize can make a people feels insignificant. Positive feelings will result in contributions above and beyond the call of duty and negative feelings will result in doing only what it takes to meet the minimum requirement. The success or failure of a project or an organization depends significantly on the manager’s role and skills and one should not take it lightly.
36.06Question: Why do we have to follow European standard such as ISO 9000?
Answer: ISO 9000 is NOT European standard but an accepted international standard. However, as a quality standard, ISO 9000’s guidelines are very broad and generic so it can apply to many areas. The issue with ISO 9000 is in the implementation – preparing the organization for ISO 9000 certification. This means doing everything the standard describe, including all the details regardless whether the organization believe it is important or not. The key benefit of ISO certification is that it allows you to demonstrate to your customers that you have in place a quality management process. This is verified by a documentation trail that documenting all necessary mechanism in detail of a quality management process as required by ISO standards.
I believe every company doing business oversea need to follow an international standard regardless the status of its local standard.
36.07 Question: How do you solve the ever-changing requirements from the ever-changing mind customers?
Answer: You need a lot of communication, patient, and skills. Never assume anything, always write down the requirement and validate with users. You may want to use prototypes technique or screen mockups to come to consensus with users. Many “ever-changing” requirements are due to the “wrong people” define requirements or capture the requirements so you need to identify the real users.
If the requirements continue to change, you may want to adopt an incremental built approach where requirements are defined in staged.
36.08 Question: We are tired of the nonsense debate about process improvement among different teams in our organization. We want to improve the process ourselves. Can we achieve level 3, 4, and 5 without the rest of the organization?
Answer: Who is stopping your group from improving yourselves? If your group can reduce defects, cycle time, manage projects according to cost and schedule projection, achieve customer satisfaction and have data to prove that you are indeed improving then why would you care about a meaningless CMM level?
Many people spend time in lengthy debate without knowing that improvement is an action not a topic for discussion. Sometime meeting is a clever way to resist the change or the act of doing something. Sometime appearing busy is a way to cover up the fact that they do not know how to make improvement works. Sometime people use “Buzz word” or “Techno-Jargon” to avoid the real simple topic of process improvement.
36.09 Question: What is the benefit of collecting defect data besides fixing defect?
Answer: Defect data (Both pre and post release) can provide a lot of information. Defect data provides insight into the software development process and the effectiveness of each phase of the software life cycle. For example, if defects keep increasing over time, we should focus our effort on the adequacy of testing, or design phase or requirements phase. The defect rate can also be used to determine if the product is stable enough for release to the customers. High number of defects identified during phase review may indicate certain problems during that phase and project manager should decide whether the software could be release into the next phase or not. Defect data can be fed back into the estimation process to estimate the expected number of defect for a particular type of job.
36.10 Question: We have used CMMI for many years with so many organizations achieved significant success. How come we do not learn from each other but continue to struggle?
Answer: Our company is very large with many diverse groups and it will take time for people to recognize that learning from one another and sharing of best practices are better than struggle to do it in isolation. That is why I formed the Software Process Improvement Network (SPIN) in 1992 as the forum to share improvement experiences. It is always wise to learn how well things are going from others and determine if your approach need refinement.
As people involve in process improvement, one must constantly ask oneself “What has gone well and what did not work well? What are issues that preventing the organization from reaching the goal? What could be done differently to make improvement works?”
36.11 Question: Please add more humor in the dry subject of process improvement.
Answer: If process improvement is a “dry-subject” then we have to find a “wet subject” such as the Noah’s Ark so here it is …
Everything I need to know about process improvement, I learned from Noah’s Ark.
1) Do not miss the boat (or improvement activities)
2) Remember, we are in the same boat (or organization)
3) Plan ahead, it was not raining when Noah built the Arks (Remember project planning KPA)
4) Stay prepare, even at 600 years old, someone may ask you to do something very big (Ready to be a Change agent, including old timers such as all Baby Boomer)
5) Do not listen to critics, or spend time in meeting just get on with the job that need to be done (So much for Intergroup Coordination)
6) Build your future on high ground (Level 5 maturity)
7) For safety’s sake, travel in pair (Work in team)
8) Faster is not always the better. The snails were on board with Cheetah. (It is the quality that count)
9) When stressed, float awhile (Do not take your job too seriously – relax and attend a SPIN)
10) The ark was built by a few people. The Titanic was built by a committee. (Thinking about OSSP Huh!)
36.12 Question: What are your thoughts on continue to attend graduate school directly after graduation from college? Or should one join the workforce first?
Answer: There are several views on whether a person should go directly to grad school or join the workforce first.
Some people believe that when you are young and motivated you should finish grad school before work since working will slow you down. Once you are busy with your career it is difficult to go back to school. When you are earning a salary, returning to school is a set back economically (not making but spending money).
However, I believe that many young college-age people really do not know much about life, and working life and should go to work for a few years to learn more – then make decision. At that time, whatever you want to go back to school or continue working, you will make the right decision.
Life is about learning continuously and working life is an experience that can help you shape your future for the better. What if you finish grad school, go to work and find out that you really do not like that job?
People does change their mind often and change is important so do not lock yourself into something you do not know very well yet.
36.13 Question: What kind of advice do you have for a new SEPG team?
Answer: Following is my 10 advices to SEPG member:
Get help from Subject-Matter-Expert early and often
You must be more proactive than you are used to being
Do not underestimate the time required to complete the tasks:
Almost all activities take longer than you think
Define the scope of improvement early
Start out with a plan just like you start a project
Don’t expect to be told what to do
Improvement is a journey not a destination and during this journey, quality honesty and integrity are not negotiable
Take time to form a successful team:
Get to know your team members
Develop trust in your team
Learn how to be comfortable with them
Continue to build on team dynamic
Establishing a team process
Clearly identify roles, responsibilities and authority
Divide tasks among team member’s ability to perform not what they want
It always takes longer and more effort than expected
Get ready for resistance to change
Do more reading, learning and sharing – No one is perfect
Understand the difficult that you face and prepare before you start the journey
